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)
|
| Список | 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 по дате отправления: