Re: pg_get__*_ddl consolidation

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_get__*_ddl consolidation
Date: 2026-04-29 15:35:07
Message-ID: CAD5tBcJMgM4oyvij7pRYxs+Fj0FqVEtHdofS1=YgiohrjZefng@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 26, 2026 at 10:07 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 2026-04-06 Mo 7:39 AM, Andrew Dunstan wrote:
> >
> > On 2026-04-05 Su 4:03 PM, Andres Freund wrote:
> >
> >
> >>> 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.
> >
> >
> >
>
> Here's a patch that converts all these into a single TAP test, and
> reduces the number of tablespace creations.
>
>
>
>
pushed.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-04-29 15:40:15 Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects
Previous Message Laurenz Albe 2026-04-29 15:32:44 Making the ENUM operators LEAKPROOF