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

From Tom Lane
Subject Re: Parallel safety tagging of extension functions
Date
Msg-id 8118.1464713278@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel safety tagging of extension functions  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: Parallel safety tagging of extension functions  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
Andreas Karlsson <andreas@proxel.se> writes:
> So how to best change the function signatures? I do not think it is 
> possible without locking indexes by just using the SQL commands. You 
> cannot drop a function from the operator family without dropping the 
> operator class first.

Ugh.  I had been thinking that you could use ALTER OPERATOR FAMILY DROP
FUNCTION, but these functions are not "loose" in the opfamily --- they're
assumed to be bound to the specific opclass.  So there's an opclass
dependency preventing them from getting dropped; and we have no SQL
commands for changing the contents of an opclass.  After some fooling
around, I couldn't find a way to do it without some manual catalog update
or other.

Given that, your original approach of manually updating proargtypes in the
existing pg_proc row for the functions may be the best way.  Anything else
is going to be more complicated and ultimately will still require at least
one direct catalog update.

Sometime we might want to think about making this sort of thing cleaner
with more ALTER commands, but post-beta is probably not the time for that;
it wouldn't be a small patch.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Josh berkus
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Tom Lane
Date:
Subject: Re: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system