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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings