Gregory Stark <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> I'll return the infomasks directly, for you to manipulate.
>> Not happy with that, but open to suggestions.

> Well the alternative would be a long list of boolean columns which would make
> the output kind of long.

> Perhaps a function pg_decode_infomask(varbit) which returns a ROW of booleans
> with appropriate names would be a good compromise. If you want it you could
> use it in your query.

This is pointless --- the function is already intended only for
debugging considerations, and anyone who needs it can be assumed capable
of ANDing with a bitmask or whatever he needs to do to inspect the
values.  I don't see anyone asking for pretty display of cmin, say,
and yet that's certainly not that easy to interpret either.

As for masks plural, I'd be inclined to merge them into one 32-bit
result --- the distinction between flag bits in infomask and infomask2
is at this point entirely historical.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to