On 03/28/2018 05:28 AM, Tom Lane wrote: > Tomas Vondra <tomas.von...@2ndquadrant.com> writes: >> On 03/27/2018 04:51 AM, David Rowley wrote: >>> Seems I didn't mean "trans types". I should have said aggregate >>> function argument types. > >> I'm not sure that's better than the check proposed by Tom. An argument >> type without send/receive function does not necessarily mean we can't >> serialize/deserialize the trans value. Because who says the argument >> value will be embedded in the trans value? > > In general we would not know that, but *for these specific serial/ > deserial functions*, we know exactly what they will do. Also, IIRC, > the trans type is declared as INTERNAL, so we don't really have any > hope of identifying the behavior by inspecting that type declaration. >
Sure, which is why I thought your solution was better, as it was targeted at those particular functions. > 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. Also, if it's checking aggref->aggargtypes, it'll reject anyelement parameters, no? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
