"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Aug 16, 2005 at 12:24:34AM -0400, Tom Lane wrote:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > So why bother with driving multiple invocations of psql under
> > > Expect. Just use DBD::Pg to open as many connections as you want and
> > > is
On Tue, Aug 16, 2005 at 12:24:34AM -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So why bother with driving multiple invocations of psql under
> > Expect. Just use DBD::Pg to open as many connections as you want and
> > issue whatever queries you want.
>
> The bit that I thin
> Yes it can, but are you going to restrict building or running
> regressions to only thos platforms that have our required modules
> installed? That might be thought a tad unfriendly.
You could include DBD::Pg with the distribution and run it locally. Perhaps
even DBI, leaving Perl the only unkn
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Another line of thought is to write a fresh implementation of the wire
>> protocol all in Perl, so as not to depend on DBI or much of anything
>> except Perl's TCP support (which I hope is reasonably well standardized
>> ;-)). If you
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide
the needed asynchronous-command-submission facility, and go forward
from there using the Perl Test framework.
How will we make
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, that would be an issue. But can't a Perl script require
>> "version >= m.n" for each module it uses?
> Yes it can, but are you going to restrict building or running
> regressions to only thos platforms that have our required m
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide
>> the needed asynchronous-command-submission facility, and go forward
>> from there using the Perl Test framework.
> How will we make sure it's consistent? People
Tom Lane wrote:
Sure, it wouldn't take much to create a minimal C+libpq program that
would do the basics. But the history of testing tools teaches that
you soon find yourself wanting a whole lot more functionality, like
conditional tests, looping, etc, in the test-driver mechanism.
That's the
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So why bother with driving multiple invocations of psql under
> > Expect. Just use DBD::Pg to open as many connections as you want and
> > issue whatever queries you want.
>
> The bit that I think is missing in DBI
Tom Lane schrieb:
Tino Wildenhain <[EMAIL PROTECTED]> writes:
Tom Lane schrieb:
The bit that I think is missing in DBI is "issue a command and don't
wait for the result just yet". ...
I might be wrong though, not being exactly a DBI guru ... can this
sort of thing be done?
I wonder if you
Tino Wildenhain <[EMAIL PROTECTED]> writes:
> Tom Lane schrieb:
>> The bit that I think is missing in DBI is "issue a command and don't
>> wait for the result just yet". ...
>> I might be wrong though, not being exactly a DBI guru ... can this
>> sort of thing be done?
>>
> I wonder if you dont ha
On Mon, Aug 15, 2005 at 06:01:20PM -0400, Tom Lane wrote:
> What we really need is a test program that can issue a command on one
> connection (perhaps waiting for it to finish, perhaps not) and then
> issue other commands on other connections, all according to a script.
Well, using Tcl with its
Tom Lane schrieb:
Greg Stark <[EMAIL PROTECTED]> writes:
So why bother with driving multiple invocations of psql under
Expect. Just use DBD::Pg to open as many connections as you want and
issue whatever queries you want.
The bit that I think is missing in DBI is "issue a command and don't
wa
Greg Stark <[EMAIL PROTECTED]> writes:
> So why bother with driving multiple invocations of psql under
> Expect. Just use DBD::Pg to open as many connections as you want and
> issue whatever queries you want.
The bit that I think is missing in DBI is "issue a command and don't
wait for the result
Tom Lane <[EMAIL PROTECTED]> writes:
> [ digs... ] It looks like what I was remembering is
> http://search.cpan.org/~lbrocard/Test-Expect-0.29/lib/Test/Expect.pm
> which seems to leave all the interesting problems (like driving more
> than one program-under-test) to the user's own devices. Sigh
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm pretty sure there are re-implementations of Expect out there that
>> don't use Tcl; would you be happier with, say, a perl-based tool?
> Yes, because we already have a dependency on perl. But don't be
> surprised if we can't find
Tom Lane wrote:
Expect is very cool, but it would impose an extra dependency on tcl that
we don't now have for building and testing,
True. I was pointing to it more as an example of the sorts of tools
people have built for this type of problem.
I'm pretty sure there are re-implementat
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Or else a harness that operates at the library/connection level rather
> than trying to control a tty app.
Right. What is sort of in the back of my mind is a C program that can
open more than one connection, and it reads a script that tells it
"fire t
Tom Lane wrote:
What we really need is a test program that can issue a command on one
connection (perhaps waiting for it to finish, perhaps not) and then
issue other commands on other connections, all according to a script.
I am unsure that the existing pg_regress infrastructure is the right
On Mon, Aug 15, 2005 at 10:37:06PM +, Matt Miller wrote:
> > Perhaps we should look at Expect or something similar.
>
> Where can I get more info on Expect?
http://www.google.com/
:-)
Or here:
http://expect.nist.gov/
--
Michael Fuhr
---(end of broadcast)-
> > Perhaps we should look at Expect or something similar.
>
> Where can I get more info on Expect?
I think I found it:
http://expect.nist.gov/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgres
> What we really need is a test program that can issue a command on one
> connection (perhaps waiting for it to finish, perhaps not) and then
> issue other commands on other connections, all according to a script.
It seems to me that this is what contrib/dblink could allow, but when I
presented th
Matt Miller <[EMAIL PROTECTED]> writes:
> The attached patch allows src/test/regress/pg_regress.sh to recognize
> lines that begin with "curr_test:" in the schedule file. Tests named on
> such a line are run concurrently across multiple connections.
This doesn't seem like any advance over the exi
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > I want to write some regression tests that confirm the behavior of
> > multiple connections simultaneously going at the same tables/rows. Is
> > there something like this already, e.g. in src/test/regr
24 matches
Mail list logo
