From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Perform COPY FROM encoding conversions in larger chunks |
Date: | 2020-12-23 07:41:43 |
Message-ID: | c0c395e6-068d-de71-869b-0a44190de159@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2020-12-23 07:51:50 | Re: Improving LWLock wait events |
Previous Message | Michael Paquier | 2020-12-23 07:38:18 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |