Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
От | Corey Huinker |
---|---|
Тема | Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands |
Дата | |
Msg-id | CADkLM=euGi8YNoHnYyXmbaD+FUiEUhe8WauMWScs_TbEawktAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: