Re: Pro et contra of preserving pg_proc oids during pg_upgrade
От | Alvaro Herrera |
---|---|
Тема | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
Дата | |
Msg-id | 202310161136.iswfvsuj7v3w@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Pro et contra of preserving pg_proc oids during pg_upgrade (Nikita Malakhov <hukutoc@gmail.com>) |
Ответы |
Re: Pro et contra of preserving pg_proc oids during pg_upgrade
|
Список | pgsql-hackers |
On 2023-Oct-13, Nikita Malakhov wrote: > Textual representation requires a long text field because it could > contain schema, arguments, it is difficult and not effective to be > saved as part of the data, and must be parsed to retrieve function > oid. It is worse than that: the regproc textual representation depends on search_path. If you store the text now, the meaning could change later, depending on the search_path that applies at read time. Of course, the storage for OID is much shorter and not subject to this problem; but it is subject to the problem that it breaks if you drop and replace the function, which could happen for instance in an extensions upgrade script. I think a better way to store a function's identity is to store the 'identity' column from pg_identify_object(). It is fully qualified and you can cast to regprocedure with no ambiguity (which gives you an OID, if you need one). And it should upgrade cleanly. If you have a regproc column that you want to upgrade, maybe it would work to do 'ALTER TABLE .. SET TYPE TEXT USING' and turn the value into pg_identify_object().identity. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: