On 03/28/2018 03:54 PM, Tom Lane wrote: > Tomas Vondra <tomas.von...@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. >
Nope, David's patch does not check what the serial/deserial functions are (and checks aggref->aggargtypes directly, not the exprType thing). >> Also, if it's checking aggref->aggargtypes, it'll reject anyelement >> parameters, no? > > I had in mind to look at exprType() of the argument. > Right, I'm fine with that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services