Wacky OID idea

Christopher Kings-Lynne dijo:

Could we overload "ALTER TABLE/DROP COLUMN oid" to allow someone to change a
table to be WITHOUT OIDs at runtime?

Create new filenode, copy tuples over, change relhasoids. Seems easy.
Am I missing something?

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"No es bueno caminar con un hombre muerto"

Alvaro Herrera <alvherre@atentus.com> writes:

Christopher Kings-Lynne dijo:

Could we overload "ALTER TABLE/DROP COLUMN oid" to allow someone to change a
table to be WITHOUT OIDs at runtime?

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.

That said, being able to remove the OIDs from a table would be fairly
useful, IMHO.

Create new filenode, copy tuples over, change relhasoids. Seems easy.
Am I missing something?

Yes -- DROP COLUMN currently doesn't require that the entire table be
re-written, it just modifies some meta-data.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

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.

Perhaps:

ALTER TABLE tab SET WITHOUT OIDS;

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?

That said, being able to remove the OIDs from a table would be fairly
useful, IMHO.

Hell yeah.

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

Chris

"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

Added to TODO:

o Add ALTER TABLE tab SET WITHOUT OIDS

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

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.

Perhaps:

ALTER TABLE tab SET WITHOUT OIDS;

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?

That said, being able to remove the OIDs from a table would be fairly
useful, IMHO.

Hell yeah.

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

Chris

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073