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 574CEAD0.1070104@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 05/25/2016 03:37 AM, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> Ok, then I can avoid touching all functions which are only called by
>> operator classes, tsearch, pls, fdws, etc. Which also means that there
>> is no need to care about Tom's changes to the signatures of GIN and GiST
>> support functions.
>
> I think as long as you already did the work, we should keep those updates.
> I'm not totally convinced by Alexander's argument that those changes pose
> a future hazard, but I'm not convinced he's wrong either.  If we're going
> to be bumping a lot of contrib module versions anyway, it'd be silly to
> take the risk that that's not a problem.

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.

Is the correct solution to manually update pg_amop with a new value for 
amopmethod?

Andreas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Redesign of parallel dump/restore's response to SIGINT
Next
From: Andreas Karlsson
Date:
Subject: Re: IPv6 link-local addresses and init data type