Re: TAP test module - PostgresClient

Thank you for the discussion.

# I didn't noticed that the license has been changed.

At Sat, 30 Dec 2017 14:35:27 -0500, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote in <4ab7546e-dd48-c985-2b26-e98d58920244(at)2ndQuadrant(dot)com>
>
>
> On 12/30/2017 10:45 AM, Tom Lane wrote:
> > Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> >> As for out-dating, if we used DBD::PgPP we'd not be not in great danger
> >> there - it doesn't appear to have changed for many years - latest
> >> version is dated 2010. If we were to use it we'd have a dependency on
> >> DBI, but that in itself doesn't seem a great burden.
> > [ blowing the dust off my old red fedora... ] Actually, there's a
> > different problem with this proposal: you can bet that DBD::Pg has got a
> > build dependency on Postgres. If Postgres starts to depend on DBD::Pg
> > then we've created circular-dependency hell for packagers.
>
> The Pure Perl driver has no such dependency, since it doesn't require
> libpq. But ...
>
> > I much prefer the other line of thought about doing whatever we need
> > to do to make psql workable for the desired type of tests.
>
> ... agreed ...

The module intends to perform multiple operations interactively
on a session, or a transaction while performing test. We must
keep the session by something persistent to do that. The
PostgresClient is that for TAP tests. If we want to let psql have
such feature, it would be something like "psql server" or
"reconnectable session" of frontend protocol. Both seem too much
or leading to something dangerous.

> > Or just
> > write a bespoke testing tool.
> >
> >
>
> ... that's pretty much where we came in.

Agreed. And we can add anything PostgreSQL or test specific
features to this.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center