Horton

Re: PG upgrade 14->15 fails - database contains our own extension

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Turoň <david.turon@linuxbox.cz>, pgsql-hackers@postgresql.org, Marian Krucina <marian.krucina@linuxbox.cz>
Date: 2022-10-13T18:51:30Z
Lists: pgsql-hackers

Attachments

I wrote:
> We might be able to put in some kluge in pg_dump to make it less
> likely to fail with existing DBs, but I think the true fix lies
> in adding that dependency.

Here's a draft patch for that.  I'm unsure whether it's worth
back-patching; even if we did, we couldn't guarantee that existing
databases would have the additional pg_depend entries.

If we do only put it in HEAD, maybe we should break compatibility
to the extent of changing IsBinaryCoercible's API rather than
inventing a separate call.  I'm still not excited about recording
additional dependencies elsewhere, but that path would leave us
with cleaner code if we eventually do that.

			regards, tom lane

Commits

  1. Record dependencies of a cast on other casts that it requires.

  2. Adjust pg_dump's priority ordering for casts.