On 06/02/2016 01:41 AM, Michael Paquier wrote:> On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson <andreas@proxel.se>
wrote:>> 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
eitherleaving the aggregate functions>> alone or updating the catalog manually.>> As this is proving to be a hassle,
whatwould 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.
I think at least three of the four aggregate functions are little used,
so I do not think many users would be affected. And only min(citext) and
max(citext) can make use of the parallel aggregation.
The functions are:
min(citext)
max(citext)
int_array_aggregate(int4)
rewrite(tsquery[])
It would be nice if we had support for this in ALTER AGGREGATE in 9.6
already since I bet that there are external extensions which want to
take advantage of the parallel aggregation, but at least if I add this
command I do not feel like it would be a minor patch. If people disagree
and are fine with copying the validation logic, then I am prepare to do
the work. I would just rather not rush this if there is no chance anyway
that it will get into 9.6.
Andreas