"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
