On Tue, 11 Jun 2024 at 13:40, fujii.y...@df.mitsubishielectric.co.jp <fujii.y...@df.mitsubishielectric.co.jp> wrote: > > From: Bruce Momjian <br...@momjian.us> > > So, we need import/export text representation for the partial aggregate > > mode for these eight, and call the base data type > > text import/export functions for the zero ones when in this mode? > > I think that you are basically right. > But, I think, in a perfect world we should also add an import/export function > for the following > two category. > > Category1. Validation Chek is needed for Safety. > For example, I think a validation check is needed for avg(float4), > whose transition type is not internal. (See p.18 in [1]) > I plan to add import functions of avg, count (See p.18, p.19 in [1]). > Category1. Transition type is a pseudo data type. > Aggregate functions of this category needs to accept many actual data > types, > including user-defined types. So I think that it is hard to implement > import/export functions. > Consequently, I do not plan to support these category. (See p.19 in [1])
How about instead of trying to serialize the output of serialfn/deserialfn, instead we don't use the "internal" type and create actual types in pg_type for these transtypes? Then we can simply use the in/out and recv/send functions of those types to serialize the values of the partial aggregate over the network. Instead of having to rely on serialfn/deserialfn to be network-safe (which they probably aren't). That indeed still leaves the pseudo types. Since non of those pseudotypes have a working in/recv function (they always error by definition), I agree that we can simply not support those. Basically that would mean that any aggregate with a non-internal and non-pseudotype as a transtype could be used in this multi-node partial aggregate pushdown.
