mirror of
https://github.com/postgres/postgres.git
synced 2025-06-11 20:28:21 +03:00
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the
default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
This commit is contained in:
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.123 2001/07/12 04:11:12 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.124 2001/08/10 18:57:32 tgl Exp $
|
||||
*
|
||||
*
|
||||
* INTERFACE ROUTINES
|
||||
@ -1027,17 +1027,10 @@ heap_get_latest_tid(Relation relation,
|
||||
}
|
||||
|
||||
/* ----------------
|
||||
* heap_insert - insert tuple
|
||||
* heap_insert - insert tuple into a heap
|
||||
*
|
||||
* The assignment of t_min (and thus the others) should be
|
||||
* removed eventually.
|
||||
*
|
||||
* Currently places the tuple onto the last page. If there is no room,
|
||||
* it is placed on new pages. (Heap relations)
|
||||
* Note that concurrent inserts during a scan will probably have
|
||||
* unexpected results, though this will be fixed eventually.
|
||||
*
|
||||
* Fix to work with indexes.
|
||||
* ----------------
|
||||
*/
|
||||
Oid
|
||||
@ -1049,18 +1042,21 @@ heap_insert(Relation relation, HeapTuple tup)
|
||||
IncrHeapAccessStat(local_insert);
|
||||
IncrHeapAccessStat(global_insert);
|
||||
|
||||
/*
|
||||
* If the object id of this tuple has already been assigned, trust the
|
||||
* caller. There are a couple of ways this can happen. At initial db
|
||||
* creation, the backend program sets oids for tuples. When we define
|
||||
* an index, we set the oid. Finally, in the future, we may allow
|
||||
* users to set their own object ids in order to support a persistent
|
||||
* object store (objects need to contain pointers to one another).
|
||||
*/
|
||||
if (!OidIsValid(tup->t_data->t_oid))
|
||||
tup->t_data->t_oid = newoid();
|
||||
else
|
||||
CheckMaxObjectId(tup->t_data->t_oid);
|
||||
if (relation->rd_rel->relhasoids)
|
||||
{
|
||||
/*
|
||||
* If the object id of this tuple has already been assigned, trust the
|
||||
* caller. There are a couple of ways this can happen. At initial db
|
||||
* creation, the backend program sets oids for tuples. When we define
|
||||
* an index, we set the oid. Finally, in the future, we may allow
|
||||
* users to set their own object ids in order to support a persistent
|
||||
* object store (objects need to contain pointers to one another).
|
||||
*/
|
||||
if (!OidIsValid(tup->t_data->t_oid))
|
||||
tup->t_data->t_oid = newoid();
|
||||
else
|
||||
CheckMaxObjectId(tup->t_data->t_oid);
|
||||
}
|
||||
|
||||
TransactionIdStore(GetCurrentTransactionId(), &(tup->t_data->t_xmin));
|
||||
tup->t_data->t_cmin = GetCurrentCommandId();
|
||||
|
Reference in New Issue
Block a user