From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Turoň <david(dot)turon(at)linuxbox(dot)cz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Marian Krucina <marian(dot)krucina(at)linuxbox(dot)cz> |
Subject: | Re: PG upgrade 14->15 fails - database contains our own extension |
Date: | 2022-10-13 16:06:46 |
Message-ID: | 965868.1665677206@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Hmm ... I think it's a very ancient bug that somehow David has avoided
> tripping over up to now.
Looking closer, I don't see how b55f2b692 could have changed pg_dump's
opinion of the order to sort these three casts in; that sort ordering
logic is old enough to vote. So I'm guessing that in fact this *never*
worked. Perhaps this extension has never been through pg_upgrade before,
or at least not with these casts?
> 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.
I don't see any painless way to fix this in pg_dump, and I'm inclined
not to bother trying if it's not a regression. Better to spend the
effort on the backend-side fix.
On the backend side, really anyplace that we consult IsBinaryCoercible
during DDL is at hazard. While there aren't a huge number of such
places, there's certainly more than just CreateCast. I'm trying to
decide how much trouble it's worth going to there. I could be wrong,
but I think that only the cast-vs-cast case is really likely to be
problematic for pg_dump, given that it dumps casts pretty early now.
So it might be sufficient to fix that one case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2022-10-13 16:18:11 | Is anybody planning to release pglogical for v15 ? |
Previous Message | Tom Lane | 2022-10-13 15:23:18 | Re: PG upgrade 14->15 fails - database contains our own extension |