From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Query execution in Perl TAP tests needs work |
Date: | 2023-09-04 15:25:39 |
Message-ID: | fc617e2e-f171-46fc-faf9-b4c5ce54c735@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-09-02 Sa 20:17, Thomas Munro wrote:
> On Sun, Sep 3, 2023 at 6:42 AM Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>
>> I confess I'm a little reluctant to impose this burden on buildfarm owners. We should think about some sort of fallback in case this isn't supported on some platform, either due to technological barriers or buildfarm owner reluctance.
> I guess you're thinking that it could be done in such a way that it is
> automatically used for $node->safe_psql() and various other things if
> Platypus is detected, but otherwise forking psql as now, for a
> transition period? Then we could nag build farm owners, and
> eventually turn off the fallback stuff after N months. After that it
> would begin to be possible to use this in more interesting and
> advanced ways.
Yeah, that would be ideal. I'll prep a version of the module that
doesn't fail if FFI::Platypus isn't available, but instead sets a flag
we can test.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-09-04 15:55:51 | Re: Commitfest 2023-09 starts soon |
Previous Message | Bruce Momjian | 2023-09-04 15:12:37 | Re: Suppressing compiler warning on Debian 12/gcc 12.2.0 |