Re: Testing with concurrent sessions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-07 02:26:29
Message-ID: 22593.1262831189@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> It just seems crazy to me to try to test anything without proper
> language bindings. Opening a psql session and parsing the results
> seems extraordinarily painful. I wonder if it would make sense write
> a small wrapper program that uses libpq and dumps out the results in a
> format that is easy for Perl to parse.

> Another idea would be to make a set of Perl libpq bindings that is
> simpler than DBD::Pg and don't go through DBI. If we put those in the
> main source tree (perhaps as a contrib module) they would be available
> wherever we need them.

We have not yet fully accepted the notion that you must have Perl to
build (and, in fact, I am right now trying to verify that you don't).
I don't think that requiring Perl to test is going to fly.

>> 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.

> That seems like a dead-end to me. It's hard for me to imagine it's
> ever going to be more than a toy.

Well, the argument there is that it might be useful for actual use,
not only testing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-01-07 02:31:20 Re: Testing with concurrent sessions
Previous Message Robert Haas 2010-01-07 01:49:38 Re: Testing with concurrent sessions