Re: Rethinking representation of partial-aggregate steps

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> Yeah, that's another way we could go. I had been considering a variant
>> of that, which was to assign specific code values to the enum constants
>> and then invent macros that did bit-anding tests on them. That ends up
>> being just about what you propose except that the compiler understands
>> the enum-ness of the behavioral alternatives, which seems like a good
>> thing.

> Isn't that what you said not to do in
> https://www.postgresql.org/message-id/13345.1462383078@sss.pgh.pa.us ?

No. What I'm imagining is, say,

#define AGGOP_COMBINESTATES 0x1
#define AGGOP_SERIALIZESTATES 0x2
#define AGGOP_DESERIALIZESTATES 0x4
#define AGGOP_FINALIZEAGGS 0x8

typedef enum AggPartialMode
{
AGGPARTIAL_SIMPLE = AGGOP_FINALIZEAGGS,
AGGPARTIAL_PARTIAL = AGGOP_SERIALIZESTATES,
AGGPARTIAL_FINAL = AGGOP_COMBINESTATES | AGGOP_DESERIALIZESTATES | AGGOP_FINALIZEAGGS
} AggPartialMode;

#define DO_AGGPARTIAL_COMBINE(apm) (((apm) & AGGOP_COMBINESTATES) != 0)
#define DO_AGGPARTIAL_SERIALIZE(apm) (((apm) & AGGOP_SERIALIZESTATES) != 0)
#define DO_AGGPARTIAL_DESERIALIZE(apm) (((apm) & AGGOP_DESERIALIZESTATES) != 0)
#define DO_AGGPARTIAL_FINALIZE(apm) (((apm) & AGGOP_FINALIZEAGGS) != 0)

These enum constants satisfy the properties I mentioned before, but their
assigned values are chosen to make the macros cheap.

regards, tom lane