On 06/01/2016 05:15 PM, Tom Lane wrote:
Andreas Karlsson <andr...@proxel.se> 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.

Thanks, I have fixed this.

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 ...

Yeah, I would have strongly preferred to be able to use the cast. All these functions have unique names within the core, but there is the small risk of someone adding a user function with the same name. I do not like either option.

The attached patch still uses to_regprocedure, but I can change to using ::regproc if that is what you prefer.


Attachment: gin-gist-signatures-v2.patch.gz
Description: application/gzip

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to