Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
Date: 2022-11-02 21:30:42
Message-ID: e0b34416-e13a-df09-17be-d63b0f1fbc6a@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.11.22 13:59, Corey Huinker wrote:
> On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com
> <mailto:peter(dot)eisentraut(at)enterprisedb(dot)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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-02 21:37:04 Re: spinlock support on loongarch64
Previous Message Andres Freund 2022-11-02 21:04:52 Re: spinlock support on loongarch64