Re: Postgres perl module namespace - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Postgres perl module namespace
Date
Msg-id 072cde16-2e07-35e2-68d0-65d097ee351d@dunslane.net
Whole thread Raw
In response to Re: Postgres perl module namespace  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2022-04-18 Mo 14:07, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> No, I think we could probably just port the whole of src/test/PostreSQL
>> back if required, and have it live alongside the old modules. Each TAP
>> test is a separate miracle - see comments elsewhere about port
>> assignment in parallel TAP tests.
>> But that would mean we have some tests in the old flavor and some in the
>> new flavor in the back branches, which might get confusing.
> That works for back-patching entire new test scripts, but not for adding
> some cases to an existing script, which I think is more common.
>
>             


I think the only thing that should trip people up in those cases is the
the new/get_new_node thing. That's complicated by the fact that the old
PostgresNode module has both new() and get_new_node(), although it
advises people not to use its new(). Probably the best way around that
is a) rename it's new() and deal with any callers, and b) add a new
new(), which would be a wrapper around get_new_node(). I'll have a play
with that.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?
Next
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname