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

From Michael Paquier
Subject Re: Parallel safety tagging of extension functions
Date
Msg-id CAB7nPqQqrbjJvYg4WcJhAB2Uf8uRxgtUt7=RHKR7VYqwwkaG0g@mail.gmail.com
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
On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson <andreas@proxel.se> wrote:
> On 05/25/2016 03:32 AM, Tom Lane wrote:
>>
>> Andreas Karlsson <andreas@proxel.se> writes:
>>>
>>> On 05/25/2016 02:41 AM, Robert Haas wrote:
>>>>
>>>> I'd rather extend see us ALTER AGGREGATE to do this.
>>
>>
>>> Wouldn't that prevent this from going into 9.6? I do not think changing
>>> ALTER AGGREGATE is 9.6 materials.
>>
>>
>> Well, it's debatable --- but if the patch to do it is small and the
>> alternatives are really ugly, that would be an acceptable choice IMO.
>> Certainly we'd want to add that capability eventually anyway.
>
>
> Looked at this quickly and I do not think adding it would be what I consider
> a small patch since we would essentially need to copy the validation logic
> from DefineAggregate and AggregateCreate and modify it to fit the alter
> case. I am leaning towards either either leaving the aggregate functions
> alone or updating the catalog manually.

As this is proving to be a hassle, what would it cost to leave those
operator classes as-is for 9.6 and come up with a cleaner solution at
DDL level with 10.0? Then we could still focus on the other extensions
that have content that can be easily switched. That's more than 90% of
the things that need to marked with parallel-safe.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PostmasterPid not marked with PGDLLIMPORT
Next
From: Andreas Karlsson
Date:
Subject: Re: Parallel safety tagging of extension functions