Re: [HACKERS] partial aggregation with internal state type
Jeff Janes writes: > On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane wrote: >> The issue is how to initialize the state value to begin with. > Why does it need to be initialized? initializing a NULL state upon first > use is already the job of sfunc. Right, but for partial aggregation the combinefunc has the same kind of role as the sfunc. > Can't it just be left NULL if both inputs > are NULL? (and use serialize/deserialize to change the memory context of > the not-NULL argument if one is NULL and one is not NULL) Huh? That would assume that the deserialize function is identical to what the combinefunc would do for the first input. I'm not sure it's even the right abstract type signature for that. I think you're also assuming too much about what the combine and deserialize functions will do in terms of memory context usage. In the end it's not very clear to me what you hope to gain here. It's not like there's any chance of omitting the combinefunc altogether. Requiring it to do something sane with a NULL initial combined state doesn't seem like much of a burden. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] partial aggregation with internal state type
On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane wrote: > Jeff Janes writes: > > The docs for creating aggregates for 9.6 and beyond say: > > "For aggregate functions whose state_data_type is internal, the > combinefunc > > must not be strict. In this case the combinefunc must ensure that null > > states are handled correctly and that the state being returned is > properly > > stored in the aggregate memory context." > > > Since combinefunc with an internal type is only useful when serialfunc > and > > deserialfunc are also defined, why can't the built-in machinery just do > the > > right thing when faced with a strict combinefunc? > > The issue is how to initialize the state value to begin with. > Why does it need to be initialized? initializing a NULL state upon first use is already the job of sfunc. Can't it just be left NULL if both inputs are NULL? (and use serialize/deserialize to change the memory context of the not-NULL argument if one is NULL and one is not NULL) Cheers, Jeff
Re: [HACKERS] partial aggregation with internal state type
Jeff Janes writes: > The docs for creating aggregates for 9.6 and beyond say: > "For aggregate functions whose state_data_type is internal, the combinefunc > must not be strict. In this case the combinefunc must ensure that null > states are handled correctly and that the state being returned is properly > stored in the aggregate memory context." > Since combinefunc with an internal type is only useful when serialfunc and > deserialfunc are also defined, why can't the built-in machinery just do the > right thing when faced with a strict combinefunc? The issue is how to initialize the state value to begin with. I suppose you're imagining that we could fill pg_aggregate.agginitval with something that the serialfunc could read. But that would place serious constraints on the serialization format, like that it be machine-independent and valid as text. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] partial aggregation with internal state type
The docs for creating aggregates for 9.6 and beyond say: "For aggregate functions whose state_data_type is internal, the combinefunc must not be strict. In this case the combinefunc must ensure that null states are handled correctly and that the state being returned is properly stored in the aggregate memory context." Since combinefunc with an internal type is only useful when serialfunc and deserialfunc are also defined, why can't the built-in machinery just do the right thing when faced with a strict combinefunc? Cheers, Jeff