Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribute, but rather their lookup should be special-cased
in the parser. And whatever we do with cmin/cmax, the infomask should
become exposed as well.
> 2. Cmin and cmax return the value that's stored on disk, whether or not
> they make sense.
This is pretty much the approach we've been taking with the past overlay
hacks --- what is returned is not always what you might expect from the
column header. I think this is tolerable as long as the infomask can be
examined to determine what's really being shown, but it's probably not
the cleanest way.
> 3. Remove cmin and cmax system columns to avoid confusion, and replace
> them with cminmax, that returns what's on disk.
Don't forget it could be xvac or "cphantom" too ;-). I think I agree
with this approach but not that particular name exactly. I'm inclined
to suggest that we just continue to use "cmin" for the field --- "cmax"
could be dropped or become an alias for "cmin".
A fourth possibility is to abandon the rule that these columns never
read as null, and to have them show their contents when meaningful
(as determined by infomask) and null otherwise. However, then we'd have
to support all of cmin, cmax, cphantom, and xvac in order to ensure that
we always have a column that can show the on-disk value.
regards, tom lane