Re: Parallel safety tagging of extension functions - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: Parallel safety tagging of extension functions
Date
Msg-id 574EF838.2040701@proxel.se
Whole thread Raw
In response to Re: Parallel safety tagging of extension functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parallel safety tagging of extension functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 06/01/2016 04:44 PM, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> It is the least ugly of all the ugly solutions I could think of. I have
>> attached a patch which fixes the signatures using this method. I use
>> CREATE OR REPLACE FUNCTION to update to catcache. What do you think? Is
>> it too ugly?
>
> 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.

CREATE FUNCTION f(text) RETURNS int LANGUAGE SQL AS $$ SELECT 1 $$;

BEGIN;

UPDATE pg_proc SET proargtypes = 
array_to_string('{int,int}'::regtype[]::oid[], ' ')::oidvector
WHERE oid = to_regprocedure('f(text)')
AND pronamespace = current_schema()::regnamespace;

ALTER FUNCTION f(int, int) STRICT;

COMMIT;

vs

CREATE FUNCTION f(text) RETURNS int LANGUAGE SQL AS $$ SELECT 1 $$;

BEGIN;

UPDATE pg_proc SET proargtypes = 
array_to_string('{int,int}'::regtype[]::oid[], ' ')::oidvector
WHERE oid = to_regprocedure('f(text)')
AND pronamespace = current_schema()::regnamespace;

CREATE OR REPLACE FUNCTION f(int, int) RETURNS int LANGUAGE SQL AS $$ 
SELECT 1 $$;

ALTER FUNCTION f(int, int) STRICT;

COMMIT;

> I think it would be good practice to be more careful about
> schema-qualifying all the pg_catalog table and type names.

I do not think we generally schema qualify things in extension scripts 
and instead rely of the CREATE/ALTER EXTENSION commands to set the 
search path correct. Am I mistaken?

> I also think it's a bad idea to use to_regprocedure() rather than
> a cast to regprocedure.  If the name isn't found, we want an error,
> not a silent NULL result leading to no update occurring.

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?

Andreas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Removing overhead commands in parallel dump/restore
Next
From: David Fetter
Date:
Subject: Re: JSON[B] arrays are second-class citizens