Re: pg_get__*_ddl consolidation - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_get__*_ddl consolidation
Date
Msg-id 5c67dc79-909a-4e17-8606-6686667da6c6@dunslane.net
Whole thread Raw
In response to Re: pg_get__*_ddl consolidation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_get__*_ddl consolidation