Re: Wacky OID idea

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> I don't think it would be easy to do this without rewriting the table,
>> as Alvaro suggested. And if you're going to give this DROP COLUMN
>> variant totally different behavior from any other form of DROP COLUMN,
>> ISTM that it doesn't belong with DROP COLUMN.

> Especially if we start saving the 4 bytes that a NULL oid takes up in a
> table tuple on disk.

It's only difficult because of the recent changes to tuple header
format.  I still feel that it's a bad idea not to be using a t_infomask
bit to indicate whether an OID field is present or not in a particular
tuple.  If we did that, then it'd be possible to implement DROP OID by
just zapping the pg_attribute entry and unsetting relhasoids in
pg_class.  As with dropping a plain column, you'd expect the space to be
reclaimed over time not instantaneously.

> I think the reverse operation would really be impossible...?  Unless we run
> through the entire table and insert an oid for each row from the oid
> counter?

Check.

> By the way - I'm not saying I'll be implementing this any time soon!

If the infomask change happens then it'd just be a few more lines of
code, at least for the DROP case which seems the more useful.

I've refrained from touching the tuple-header issues until Manfred
returns from vacation and can defend himself ;-) ... but that stuff
definitely needs to get addressed in the next week or two.
        regards, tom lane