Re: Parallel safety tagging of extension functions

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel safety tagging of extension functions
Date: 2016-06-01 14:59:04
Message-ID: 574EF838.2040701@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/01/2016 04:44 PM, Tom Lane wrote:
> Andreas Karlsson <andreas(at)proxel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2016-06-01 15:03:01 Re: JSON[B] arrays are second-class citizens
Previous Message Tom Lane 2016-06-01 14:57:53 Removing overhead commands in parallel dump/restore