Re: pg_get__*_ddl consolidation

On 2026-04-05 Su 4:03 PM, Andres Freund wrote:
> Hi,
>
> On 2026-04-05 11:40:33 -0400, Andres Freund wrote:
>> On 2026-04-05 11:06:09 -0400, Andrew Dunstan wrote:
>>> Pushed. I have moved the remaining get_*_ddl items to PG20-1
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2026-04-05%2015%3A04%3A04
>>
>> diff -U3 /Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/database_ddl.out /Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/database_ddl.out
>> --- /Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/database_ddl.out 2026-04-05 11:04:08
>> +++ /Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/database_ddl.out 2026-04-05 11:05:57
>> @@ -22,6 +22,7 @@
>> CREATE DATABASE regress_database_ddl
>> ENCODING utf8 LC_COLLATE "C" LC_CTYPE "C" TEMPLATE template0
>> OWNER regress_datdba;
>> +WARNING: databases created by regression test cases should have names including "regression"
>> ALTER DATABASE regress_database_ddl CONNECTION_LIMIT 123;
>> ALTER DATABASE regress_database_ddl SET random_page_cost = 2.0;
>> ALTER ROLE regress_datdba IN DATABASE regress_database_ddl SET random_page_cost = 1.1;
> Pushed a fixup for this and the pgindent failure, as it doesn't seem like a
> great time to have CI/BF fail.

Thanks for that. I'm not sure how my test regime managed to miss either.
I will work on that.

> It is pretty odd that the naming restrictions for databases (regression*) is
> different than for all the other object types...
>

Yeah.

>> But do we really have to create a new database and a new tablespace for these?
>> Database and tablespace creations are quite heavyweight operations.
>>
>> We already have an existing tablespace and an existing database as part of the
>> regression tests. Couldn't you make do with those?
> Didn't do anything about that.
>

Well, the trouble is that the database test runs a bunch of alter and
revoke statements on the created database, that we probably don't want
to persist on the existing regression database. I could see an argument
for converting this to a TAP test that would only be run once, given our
current very profligate running of the core regression suite. That goes
doubly for the tablespace test, which could also probably use ALTER
TABLESPACE instead of creating a bunch of tablespaces and then dropping
them.

cheers

andrew

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