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.
Andreas
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: http://www.postgresql.org/mailpref/pgsql-hackers
