Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 03/28/2018 05:28 AM, Tom Lane wrote:
>> Getting a solution that would work for other polymorphic serialization
>> functions seems like a bit of a research project to me. In the meantime,
>> I think David's right that what we need to look at is the actual input
>> type of the aggregate, and then assume that what's to be serialized is
>> an array of that. Conceivably an aggregate could be built that uses
>> these serial/deserial functions and yet its input type is something else
>> than what it constructs an array of ... but I find it a bit hard to
>> wrap my brain around what that would be exactly.
> But David's fix doesn't check the aggregate to produce an array of the
> input type (or anyarray). It could easily be an aggregate computing a
> bloom filter or something like that, which has no such issues in the
> serial/deserial functions.
Oh, if he's not restricting it to these serialization functions, I agree
that seems wrong. I thought the discussion was about what to do after
checking the functions.
> Also, if it's checking aggref->aggargtypes, it'll reject anyelement
> parameters, no?
I had in mind to look at exprType() of the argument.
regards, tom lane
