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