Re: OID wraparound (was Re: pg_depend) - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: OID wraparound (was Re: pg_depend)
Date
Msg-id 20010718184506.B29140@rice.edu
Whole thread Raw
In response to Re: OID wraparound (was Re: pg_depend)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OID wraparound (was Re: pg_depend)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 18, 2001 at 04:06:28PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: "Rod Taylor"
Date:
Subject: Re: OID wraparound (was Re: pg_depend)
Next
From: Tom Lane
Date:
Subject: Re: OID wraparound (was Re: pg_depend)