Re: Cannot create an aggregate function with variadic parameters and enabled for parallel execution

From: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Cannot create an aggregate function with variadic parameters and enabled for parallel execution
Date: 2018-05-16 15:18:42
Message-ID: 29f43d04-f458-f623-75e8-d4ab27c44de5@imap.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 15/05/18 17:52, Tom Lane wrote:
>
> For the combine function, it seems fine to just say that the function
> signature is alway "combine(stype, stype) returns stype" even in
> polymorphic cases. "combine(anyarray, anyarray) returns anyarray"
> is a perfectly legal function declaration, so there's no problem at
> that end. At runtime, the combine function could inspect its argument
> to find out what the array element type is. In cases that are like
> "combine(internal, internal) returns internal", the function declaration
> is still acceptable. The representation of the internal-type state
> value would need to contain enough information for the combine function
> to do its work without additional type lookups --- but that would likely
> need to be true anyway, so it does not seem like a big penalty.
>
> For the serial/deserial functions, the function signatures are
> prespecified and don't depend on the aggregate argument types, so
> there's no declaration issue. Again, the state value would need
> to be sufficiently self-contained for the functions to not need
> additional info to figure out how to serialize it --- but again,
> I do not see much problem there.

Sounds reasonable, aggregate arguments type info is not necessary for
combine/de-/serialize declarations, and for execution it could be
passed in the state variable.

> So I think we're okay with solving this as per your patch, though
> it needs some more comments IMO. Will push.

Do you mean it needs to be discussed more, or it needs more
inline code comments?

>
> BTW, I noticed while looking at this that this error message in
> nodeAgg.c seems to be exactly backwards:
>
> /*
> * Ensure that a combine function to combine INTERNAL states is not
> * strict. This should have been checked during CREATE AGGREGATE, but
> * the strict property could have been changed since then.
> */
> if (pertrans->transfn.fn_strict && aggtranstype == INTERNALOID)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
> errmsg("combine function for aggregate %u must be declared as STRICT",
> aggref->aggfnoid)));
> }
>
> Should be "must *not* be declared STRICT", no?

Agree, this must have been a typo.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Rick Gentry 2018-05-16 16:04:42 Re: "order by" and "order by asc" returning different results on date field
Previous Message Pavel Stehule 2018-05-16 15:10:58 Re: Abnormal JSON query performance