Re: bad dependency in pg_dump output related to support function breaks binary upgrade - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: bad dependency in pg_dump output related to support function breaks binary upgrade
Date
Msg-id CAFj8pRBngya6-ZA0y3YRpZ5qrAi4gi5ipZhw9fEeZC5aTLU9Fg@mail.gmail.com
Whole thread Raw
In response to Re: bad dependency in pg_dump output related to support function breaks binary upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


po 21. 12. 2020 v 17:23 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> some Orafce's user reported problems with pg_upgrade. I checked this issue
> and it looks like pg_dump problem:
> ...
> the supporting function should be dumped first before function where
> supporting function is used.

I tried to reproduce this and could not.  It should work, since
ProcedureCreate definitely makes a dependency on the support function.
Can you make a self-contained test case?

After some deeper investigation I found an old bug in Orafce :-/. I am sorry for the noise.

This old bug is related to introduction aliases types of varchar - nvarchar2 and varchar2. In this age the "in" function can use a protransform column, but there was not a possibility how to set this column externally, and Orafce used dirty update. The value was correct, but the new dependency was not used. Originally it was not a problem, because the transform function was built in. But there was a new issue related to Postgres 12 when these functions were renamed. I fixed this issue by introducing my own wrapping function - but without dependency I broke the binary upgrade.

On Postgres 12 and higher I can use ALTER FUNCTION SUPPORT and all works well. On older platforms I have to hack pg_depend, but it is working too.

Again I am sorry for false alarm

Regards

Pavel


 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Weird special case in jsonb_concat()
Next
From: Tom Lane
Date:
Subject: Re: BUG #16079: Question Regarding the BUG #16064