Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
От | Peter Eisentraut |
---|---|
Тема | Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands |
Дата | |
Msg-id | e0b34416-e13a-df09-17be-d63b0f1fbc6a@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands (Corey Huinker <corey.huinker@gmail.com>) |
Ответы |
Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands
|
Список | 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 по дате отправления: