"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
>> My thought is to make OID generation optional on a per-table basis, and
>> disable it on system tables that don't need unique OIDs. (OID would
>> read as NULL on any row for which an OID wasn't generated.)
> How about generalizing this to user defineable system attributes? OID
> would just be a special case: it's really just a system 'serial' isn't it?
Hmm. Of the existing system attributes, OID is the only one that's
conceivably optional --- ctid,xmin,xmax,cmin,cmax are essential to
the functioning of the system. (tableoid doesn't count here, since
it's a "virtual" attribute that doesn't occupy any storage space on
disk, and thus making it optional wouldn't buy anything.) So there's
no gain to be seen in that direction.
In the other direction, I have no desire to buy into adding creation
timestamp or anything else in this go-round. Maybe sometime in the
future.
BTW, I'm not intending to change the on-disk format of tuple headers;
if no OID is assigned to a row, the OID field will still be there,
it'll just be 0. Given that it's only four bytes, it's probably not
worth dealing with a variable header format to suppress the space usage.
(On machines where MAXALIGN is 8 bytes, there likely wouldn't be any
savings anyway.)
I wouldn't much care for dealing with a variable tuple header format to
support creation timestamp either, and that leads to the conclusion that
it's just going to be a user field anyway. People who need it can do it
with a trigger ...
> I'm not sure the special behavior of returning NULL for oid on a table
> without one is going to be useful: any client code that expects everything
> to have an oid is unlikely to handle NULL better than an error.
Well, I can see three possible choices: return NULL, return zero, or
don't create an OID entry in pg_attribute at all for such a table
(I *think* that would be sufficient to prevent people from accessing
the OID column, but am not sure). Of these I'd think the first is
least likely to break stuff. However, you might be right that breaking
stuff is preferable to the possibility of an app that thinks it knows
what it's doing causing major data lossage because it doesn't.
regards, tom lane