database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-08 11:42:09 +03:00
Code Activity

Store table oid and tuple's tid in tuple slots directly.

Browse Source 
After the introduction of tuple table slots all table AMs need to
support returning the table oid of the tuple stored in a slot created
by said AM. It does not make sense to re-implement that in every AM,
therefore move handling of table OIDs into the TupleTableSlot
structure itself.  It's possible that we, at a later date, might want
to get rid of HeapTupleData.t_tableOid entirely, but doing so before
the abstractions for table AMs are integrated turns out to be too
hard, so delay that for now.

Similarly, every AM needs to support the concept of a tuple
identifier (tid / item pointer) for its tuples. It's quite possible
that we'll generalize the exact form of a tid at a future point (to
allow for things like index organized tables), but for now many parts
of the code know about tids, so there's not much point in abstracting
tids away. Therefore also move into slot (rather than providing API to
set/get the tid associated with the tuple in a slot).

Once table AM includes insert/updating/deleting tuples, the
responsibility to set the correct tid after such an action will move
into that. After that change, code doing such modifications, should
not have to deal with HeapTuples directly anymore.

Author: Andres Freund, Haribabu Kommi and Ashutosh Bapat
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
This commit is contained in:
Andres Freund
2019-02-26 18:21:44 -08:00
parent 5408e233f0
commit b8d71745ea
7 changed files with 69 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/commands/copy.c
View File

@ -2710,10 +2710,10 @@ CopyFrom(CopyState cstate)
tuple = heap_form_tuple(tupDesc, values, nulls);
/*
* Constraints might reference the tableoid column, so initialize
* t_tableOid before evaluating them.
* Constraints might reference the tableoid column, so (re-)initialize
* tts_tableOid before evaluating them.
*/
tuple->t_tableOid = RelationGetRelid(target_resultRelInfo->ri_RelationDesc);
myslot->tts_tableOid = RelationGetRelid(target_resultRelInfo->ri_RelationDesc);
/* Triggers and stuff need to be invoked in query context. */
MemoryContextSwitchTo(oldcontext);
@ -2899,7 +2899,7 @@ CopyFrom(CopyState cstate)
MemoryContextSwitchTo(oldcontext);
}
tuple->t_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
slot->tts_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
}
skip_tuple = false;
@ -2995,14 +2995,18 @@ CopyFrom(CopyState cstate)
/*
* AFTER ROW Triggers might reference the tableoid
* column, so initialize t_tableOid before evaluating
* them.
* column, so (re-)initialize tts_tableOid before
* evaluating them.
*/
tuple->t_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
slot->tts_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
}
else
{
heap_insert(resultRelInfo->ri_RelationDesc, tuple,
mycid, hi_options, bistate);
ItemPointerCopy(&tuple->t_self, &slot->tts_tid);
slot->tts_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
}
/* And create index entries for it */
if (resultRelInfo->ri_NumIndices > 0)