Re: Perform COPY FROM encoding conversions in larger chunks

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Perform COPY FROM encoding conversions in larger chunks
Дата
Msg-id c0c395e6-068d-de71-869b-0a44190de159@iki.fi
обсуждение исходный текст
Ответ на Re: Perform COPY FROM encoding conversions in larger chunks  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: Perform COPY FROM encoding conversions in larger chunks  (John Naylor <john.naylor@enterprisedb.com>)
Re: Perform COPY FROM encoding conversions in larger chunks  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers
On 22/12/2020 22:01, John Naylor wrote:
> In 0004, it seems you have some doubts about upgrade compatibility. Is 
> that because user-defined conversions would no longer have the right 
> signature?

Exactly. If you have an extension that adds a custom conversion function 
and does CREATE CONVERSION, the old installation script will fail on the 
new version. That causes trouble for pg_dump+restore and pg_upgrade.

Perhaps we could accept the old signature in the server when you do 
CREATE CONVERSION, but somehow mark the conversion as broken in the 
catalog so that you would get a runtime error if you tried to use it. 
That would be enough to make pg_dump+restore (and pg_upgrade) not throw 
an error, and you could then upgrade the extension later (ALTER 
EXTENSION UPDATE).

I'm not sure it's worth the trouble, though. Custom conversions are very 
rare. And I don't think any other object can depend on a conversion, so 
you can always drop the conversion before upgrade, and re-create it with 
the new function signature afterwards. A note in the release notes and a 
check in pg_upgrade, with instructions to drop and recreate the 
conversion, are probably enough.

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "k.jamison@fujitsu.com"
Дата:
Сообщение: RE: [Patch] Optimize dropping of relation buffers using dlist
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Improving LWLock wait events