Horton

Thread

Commits

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

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

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-10-24T09:54:28Z

    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.

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

    Corey Huinker <corey.huinker@gmail.com> — 2022-11-01T17:59:28Z

    On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut <
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.

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?

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

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-11-02T21:30:42Z

    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?

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

    Corey Huinker <corey.huinker@gmail.com> — 2022-11-05T17:39:09Z

    On Wed, Nov 2, 2022 at 5:30 PM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

> 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?
>

Sorry for the confusion, I was thinking strictly of the in memory
representation after it is extracted from the dictionary.