From: Robert Haas on 7 Jan 2010 11:57 On Thu, Jan 7, 2010 at 11:46 AM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Using DBI/DBD::Pg would raise another issue - what version of libpq would it > be using? Not the one in the build being tested, that's for sure. If you > really want to use Perl then either a Pure Perl DBI driver (which Greg has > talked about) or a thin veneer over libpq such as we used to have in contrib > seems a safer way to go. I completely agree. As between those two options, count me as +1 for the thin veneer. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 7 Jan 2010 11:58 On Wed, Jan 06, 2010 at 08:40:28PM -0500, Andrew Dunstan wrote: > A parallel psql seems to me a better way to go. We talked about that > a while ago, but I don't recall what happened to it. Greg Stark had a patch a couple of years ago. Dunno what happened to it since then. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 7 Jan 2010 12:08 On Jan 6, 2010, at 6:31 PM, Kevin Grittner wrote: > As far as I've been able to determine so far, to call psql in a > relatively portable way would require something like this: > > http://perldoc.perl.org/perlfork.html Here's an example using IPC::Open3: #!/usr/local/bin/perl -w use strict; use warnings; use IPC::Open3; use Symbol 'gensym'; use constant EOC => "__DONE__\n"; my ($in1, $out1, $err1) = (gensym, gensym, gensym); my ($in2, $out2, $err2) = (gensym, gensym, gensym); my $pid1 = open3 $in1, $out1, $err1, 'bash'; my $pid2 = open3 $in2, $out2, $err2, 'bash'; print $in1 "cd ~/dev/postgresql\n"; print $in1 "ls doc\n"; print $in1 "echo ", EOC; while ((my $line = <$out1>)) { last if $line eq EOC; print "LS: $line"; } print "#### Finished file listing\n\n"; print $in2 "cd ~/dev/postgresql\n"; print $in2 "head -4 README\n"; print $in2 "echo ", EOC; while (defined( my $line = <$out2> )) { last if $line eq EOC; print "HEAD: $line"; } print "#### Finished reading README\n\n"; print $in1 "exit\n"; print $in2 "exit\n"; waitpid $pid2, 0; print "#### All done!\n"; With that, I get: LS: KNOWN_BUGS LS: MISSING_FEATURES LS: Makefile LS: README.mb.big5 LS: README.mb.jp LS: TODO LS: bug.template LS: src #### Finished file listing HEAD: PostgreSQL Database Management System HEAD: ===================================== HEAD: HEAD: This directory contains the source code distribution of the PostgreSQL #### Finished reading README #### All done! I could easily write a very simple module to abstract all that stuff for you, then you could just do something like: my $psql1 = Shell::Pipe->new(qw(psql -U postgres)); my $psql2 = Shell::Pipe->new(qw(psql -U postgres)); $psql1->print('SELECT * from pg_class'); while (my $line = $psql1->readln) { print "Output: $line\n" } $psql1->close; All I'd need is some more reliable way than "echo "DONE__\n" to be able to tell when a particular command has finished outputting. Thoughts? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 Jan 2010 12:08 Andrew Dunstan <andrew(a)dunslane.net> writes: > Unless I am mistaken, Perl is required in any case to build from CVS, > although not from a tarball. Right, but to my mind "building from a tarball" needs to include the ability to run the regression tests on what you built. So injecting Perl into that is moving the goalposts on build requirements. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 7 Jan 2010 12:10
On Jan 7, 2010, at 9:08 AM, Tom Lane wrote: > Right, but to my mind "building from a tarball" needs to include the > ability to run the regression tests on what you built. So injecting > Perl into that is moving the goalposts on build requirements. In that case, there's nothing for it except concurrent psql. Or else some sort of shell environment that's available on all platforms. do we require bash on Windows? Oh, wait, the Windows build requires PerlÂ… Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |