Re: OID wraparound (was Re: pg_depend)

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: OID wraparound (was Re: pg_depend)
Дата
Msg-id 20010718184506.B29140@rice.edu
обсуждение исходный текст
Ответ на Re: OID wraparound (was Re: pg_depend)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: OID wraparound (was Re: pg_depend)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Rod Taylor"
Дата:
Сообщение: Re: OID wraparound (was Re: pg_depend)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: OID wraparound (was Re: pg_depend)