Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
Date
Msg-id e0b34416-e13a-df09-17be-d63b0f1fbc6a@enterprisedb.com
Whole thread Raw
In response to Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
List pgsql-hackers
On 01.11.22 13:59, Corey Huinker wrote:
> On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut 
> <peter.eisentraut@enterprisedb.com 
> <mailto:peter.eisentraut@enterprisedb.com>> wrote:
> 
>     Avoid having to list all the possible object types twice.  Instead,
>     only
>     _getObjectDescription() needs to know about specific object types.  It
>     communicates back to _printTocEntry() whether an owner is to be set.
> 
>     In passing, remove the logic to use ALTER TABLE to set the owner of
>     views and sequences.  This is no longer necessary.  Furthermore, if
>     pg_dump doesn't recognize the object type, this is now a fatal error,
>     not a warning.
> 
> 
> Makes sense, passes all tests.

Committed.

> It's clearly out of scope for this very focused patch, but would it make 
> sense for the TocEntry struct to be populated with an type enumeration 
> integer as well as the type string to make for clearer and faster 
> sifting later?

That could be better, but wouldn't that mean a change of the format of 
pg_dump archives?



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: spinlock support on loongarch64
Next
From: Tom Lane
Date:
Subject: Re: spinlock support on loongarch64