Andreas Karlsson <> writes:
> On 06/01/2016 04:44 PM, Tom Lane wrote:
>> I don't understand why you think you need the CREATE OR REPLACE FUNCTION
>> commands?  We only need to change proargtypes, and the updates did that.
>> The catcache can take care of itself.

> Maybe I did something wrong (I try to avoid doing manual catalog 
> updates), but when I tested it, I needed to run the CREATE OR REPLACE 
> FUNCTION command to later be able to set the parallel safety. See the 
> example below.

In this particular example, the problem seems to be that you forgot to
update pronargs; it works for me when I add "pronargs = 2" to the UPDATE.
Your "working" example is actually creating a new function, not replacing
the old pg_proc entry.

BTW, it strikes me that the pronamespace tests in these queries are
redundant: the OID is unique, so what matters is the search path
in the regprocedure lookups.

> The reason I use to_regprocedure is so that these scripts work for 
> people who have installed the extensions in beta1 and therefore only 
> have the new signatures. If they run these scripts they would get an 
> error if I used the cast. Is it ok if these scripts break for beta1 users?

Ugh.  This is more of a mess than I thought.  I don't like update scripts
that might silently fail to do what they're supposed to, but leaving
beta1 users in the lurch is not very nice either.

I wonder ... could we get away with using regproc rather than
regprocedure?  These function names are probably unique anyway ...

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to