From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Query execution in Perl TAP tests needs work |
Date: | 2023-08-29 04:33:48 |
Message-ID: | CA+hUKGKyubv1Jq+qC7eyE+2GE3jootRMX0TdGU7PvyhejFQ_Xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 29, 2023 at 1:23 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I like the idea of using a pure perl pq implementation, not least because it could expand our ability to test things at the protocol level. Not sure how much work it would be. I'm willing to help if we want to go that way.
Cool. Let's see what others think.
And assuming we can pick *something* vaguely efficient and find a Perl
hacker to implement it, a related question is how to expose it to our
test suites.
Should we figure out how to leave all our tests unchanged, by teaching
$node->psql() et al to do caching implicitly? Or should we make it
explicit, with $conn = $node->connect(), and $conn->do_stuff()? And
if the latter, should do_stuff be DBI style or something that suits us
better?
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-08-29 04:46:18 | Re: persist logical slots to disk during shutdown checkpoint |
Previous Message | Thomas Munro | 2023-08-29 04:25:24 | Re: Query execution in Perl TAP tests needs work |