I wrote:
> ... Now, when the bitmap is present, it would be fairly tedious
> to calculate the length of the bitmap to determine the offset to the
> actual data; and that's an operation that we'd like to be cheap. What
> I'm thinking of doing is commandeering the whole "flags" field of
> ArrayType (which is currently unused and should be always zero), and
> redefining it thus:
> zero: bitmap not present (fully backwards-compatible case)
> not zero: bitmap is present; value is offset to start of data
> I wouldn't propose doing this if I thought we had any pressing reason
> to save some array flag bits for some other purpose; but I can't think
> of anything else we might want 'em for. Did anyone have any pet ideas
> this would foreclose?
On trying to recompile things, I find that contrib/intarray is broken
by this change, because it's using the flags field for its own purposes:
/** flags for gist__int_ops, use ArrayType->flags* which is unused (see array.h)*/
#define LEAFKEY (1<<31)
#define ISLEAFKEY(x) ( ((ArrayType*)(x))->flags & LEAFKEY )
It seems likely that intarray is going to need some rather significant
work anyway to deal with null elements, so this seems to me to be not
necessarily a fatal objection. But why exactly does intarray need to
play games with the contents of an array value?
regards, tom lane
