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