Re: OID wraparound (was Re: pg_depend)

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OID wraparound (was Re: pg_depend)
Date: 2001-07-18 23:45:06
Message-ID: 20010718184506.B29140@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Is the idea to make oid's optional, with them disabled by default on
> > user tables?
>
> 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?

We occasionally get calls for other system type attributes that would
be too expensive for every table, but would be useful for individual
tables. One is creation_timestamp. Or this could be a route to bringing
timetravel back in: start_date stop_date, anyone?

>
> It remains to be debated exactly how users should control the choice for
> user tables, and which choice ought to be the default. I don't have a
> strong opinion about that either way, and am prepared to hear
> suggestions.

Two ways come to mind: either special WITH options, at the end, or
a new per attribute SYSTEM keyword:

CREATE TABLE <...> WITH OIDS
CREATE TABLE <...> WITH TIMETRAVEL
CREATE TABLE <...> WITH DATESTAMP

CREAT TABLE foo (oid oid SYSTEM,
created timestamp SYSTEM DEFAULT CURRENT_TIMESTAMP,
my_id serial,
my_field text);

So, basically it just creates the type and gives it a negative attnum.
The 'oid system' case would need to be treated specially, hooking the
oid up to the system wide counter.

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. In fact,
in combination with the MS-Access compatability hack of '= NULL' as
'IS NULL', I see a potential great loss of data:

SELECT oid,* from some_table;

<display to user for editing>

UPDATE some_table set field1=$field1, field2=$field2, <...> WHERE oid = $oid;

if $oid is NULL ... There goes the entire table.

Ross

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-18 23:47:38 Re: OID wraparound (was Re: pg_depend)
Previous Message Sascha Schumann 2001-07-18 23:44:51 Re: MySQL Gemini code