Re: Add more sanity checks around callers of changeDependencyFor()
От | Alvaro Herrera |
---|---|
Тема | Re: Add more sanity checks around callers of changeDependencyFor() |
Дата | |
Msg-id | 20230710145506.owzwozljbznde3cd@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Add more sanity checks around callers of changeDependencyFor() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add more sanity checks around callers of changeDependencyFor()
|
Список | pgsql-hackers |
On 2023-Jul-10, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: > > On Thu, Jul 06, 2023 at 10:09:20AM -0700, Andres Freund wrote: > >> I also don't think pg_dump will dump the changed schema, which means a > >> dump/restore leads to a different schema - IMO something to avoid. > > > Yes, you're right here. The function dumped is restored in the same > > schema as the extension. > > Actually, I think the given example demonstrates pilot error rather > than a bug. Well, if this is pilot error, why don't we throw an error ourselves? > The user has altered properties of an extension member > object locally within the database, but has not changed the extension's > installation script to match. If I were developing an extension and decided, down the line, to have some objects in another schema, I would certainly increment the extension's version number and have a new script to move the object. I would never expect the user to do an ALTER directly (and it makes no sense for me as an extension developer to do it manually, either.) -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ “Cuando no hay humildad las personas se degradan” (A. Christie)
В списке pgsql-hackers по дате отправления: