Re: Сreate parallel aggregate

Thank you for the detailed answer.
I think a less obscure error message would be a good thing.

On 09/29/2016 05:26 PM, Tom Lane wrote:
> Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru> writes:
>> I was trying to create a parallel aggregate with base_type parameter and
>> failed
>> postgres=# CREATE AGGREGATE ST_Extent_parallel (
>> sfunc = ST_CombineBBox,
>> combinefunc = ST_CombineBBox,
>> finalfunc = box2d,
>> stype = box3d,
>> basetype = geometry,
>> parallel = safe
>> );
>> ERROR: syntax error at or near "parallel"
>> LINE 7: parallel = safe
> Old-style CREATE AGGREGATE syntax is only meant to be used with the
> options that existed at the time it was deprecated. It's unfortunate that
> the error message is so obscure, but Bison doesn't give us a lot of wiggle
> room to make it better, and frankly I don't especially care to put much
> effort into that anyway. (The actual problem is that old_aggr_elem
> has to use IDENT to avoid reduce/reduce conflicts, so none of the option
> names can be keywords at all, not even unreserved ones.)
>
> If we do anything about this at all, what I'd be inclined to do is shove
> the old-style syntax into a footnote at the bottom of the reference page,
> similarly to the way the legacy syntaxes for COPY are documented.
> And probably we should strip out all but the historical options from
> the list that we claim works with it.
>
> A more aggressive answer would be to drop the old-style CREATE AGGREGATE
> syntax altogether ... but seeing that we're still supporting pre-7.3 COPY
> syntax, probably that won't fly.
>
> regards, tom lane

--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company