Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit73b8c3b

Browse files
committed
tableam: Rename wrapper functions to match callback names.
Some of the wrapper functions didn't match the callback names. Many ofthem due to staying "consistent" with historic naming of the wrappedfunctionality. We decided that for most cases it's more important tobe for tableam to be consistent going forward, than with the past.The one exception is beginscan/endscan/... because it'd have lookedodd to have systable_beginscan/endscan/... with a different namingscheme, and changing the systable_* APIs would have caused way toomuch churn (including breaking a lot of external users).Author: Ashwin Agrawal, with some small additions by Andres FreundReviewed-By: Andres FreundDiscussion:https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com
1 parent54487d1 commit73b8c3b

File tree

14 files changed

+178
-169
lines changed

14 files changed

+178
-169
lines changed

‎src/backend/access/heap/heapam.c‎

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1866,12 +1866,12 @@ ReleaseBulkInsertStatePin(BulkInsertState bistate)
18661866
* The new tuple is stamped with current transaction ID and the specified
18671867
* command ID.
18681868
*
1869-
* Seetable_insert for comments about most of the input flags, except that
1870-
* this routine directly takes a tuple rather than a slot.
1869+
* Seetable_tuple_insert for comments about most of the input flags, except
1870+
*thatthis routine directly takes a tuple rather than a slot.
18711871
*
18721872
* There's corresponding HEAP_INSERT_ options to all the TABLE_INSERT_
18731873
* options, and there additionally is HEAP_INSERT_SPECULATIVE which is used to
1874-
* implementtable_insert_speculative().
1874+
* implementtable_tuple_insert_speculative().
18751875
*
18761876
* On return the header fields of *tup are updated to match the stored tuple;
18771877
* in particular tup->t_self receives the actual TID where the tuple was
@@ -2444,8 +2444,8 @@ xmax_infomask_changed(uint16 new_infomask, uint16 old_infomask)
24442444
/*
24452445
*heap_delete - delete a tuple
24462446
*
2447-
* Seetable_delete() for an explanation of the parameters, except that this
2448-
* routine directly takes a tuple rather than a slot.
2447+
* Seetable_tuple_delete() for an explanation of the parameters, except that
2448+
*thisroutine directly takes a tuple rather than a slot.
24492449
*
24502450
* In the failure cases, the routine fills *tmfd with the tuple's t_ctid,
24512451
* t_xmax (resolving a possible MultiXact, if necessary), and t_cmax (the last
@@ -2890,8 +2890,8 @@ simple_heap_delete(Relation relation, ItemPointer tid)
28902890
/*
28912891
*heap_update - replace a tuple
28922892
*
2893-
* Seetable_update() for an explanation of the parameters, except that this
2894-
* routine directly takes a tuple rather than a slot.
2893+
* Seetable_tuple_update() for an explanation of the parameters, except that
2894+
*thisroutine directly takes a tuple rather than a slot.
28952895
*
28962896
* In the failure cases, the routine fills *tmfd with the tuple's t_ctid,
28972897
* t_xmax (resolving a possible MultiXact, if necessary), and t_cmax (the last
@@ -3961,7 +3961,7 @@ get_mxact_status_for_lock(LockTupleMode mode, bool is_update)
39613961
**buffer: set to buffer holding tuple (pinned but not locked at exit)
39623962
**tmfd: filled in failure cases (see below)
39633963
*
3964-
* Function results are the same as the ones fortable_lock_tuple().
3964+
* Function results are the same as the ones fortable_tuple_lock().
39653965
*
39663966
* In the failure cases other than TM_Invisible, the routine fills
39673967
* *tmfd with the tuple's t_ctid, t_xmax (resolving a possible MultiXact,

‎src/backend/access/table/tableam.c‎

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -221,7 +221,7 @@ table_index_fetch_tuple_check(Relation rel,
221221
*/
222222

223223
void
224-
table_get_latest_tid(TableScanDescscan,ItemPointertid)
224+
table_tuple_get_latest_tid(TableScanDescscan,ItemPointertid)
225225
{
226226
Relationrel=scan->rs_rd;
227227
constTableAmRoutine*tableam=rel->rd_tableam;
@@ -248,36 +248,36 @@ table_get_latest_tid(TableScanDesc scan, ItemPointer tid)
248248
*/
249249

250250
/*
251-
*simple_table_insert - insert a tuple
251+
*simple_table_tuple_insert - insert a tuple
252252
*
253-
* Currently, this routine differs fromtable_insert only in supplying a
253+
* Currently, this routine differs fromtable_tuple_insert only in supplying a
254254
* default command ID and not allowing access to the speedup options.
255255
*/
256256
void
257-
simple_table_insert(Relationrel,TupleTableSlot*slot)
257+
simple_table_tuple_insert(Relationrel,TupleTableSlot*slot)
258258
{
259-
table_insert(rel,slot,GetCurrentCommandId(true),0,NULL);
259+
table_tuple_insert(rel,slot,GetCurrentCommandId(true),0,NULL);
260260
}
261261

262262
/*
263-
*simple_table_delete - delete a tuple
263+
*simple_table_tuple_delete - delete a tuple
264264
*
265265
* This routine may be used to delete a tuple when concurrent updates of
266266
* the target tuple are not expected (for example, because we have a lock
267267
* on the relation associated with the tuple). Any failure is reported
268268
* via ereport().
269269
*/
270270
void
271-
simple_table_delete(Relationrel,ItemPointertid,Snapshotsnapshot)
271+
simple_table_tuple_delete(Relationrel,ItemPointertid,Snapshotsnapshot)
272272
{
273273
TM_Resultresult;
274274
TM_FailureDatatmfd;
275275

276-
result=table_delete(rel,tid,
277-
GetCurrentCommandId(true),
278-
snapshot,InvalidSnapshot,
279-
true/* wait for commit */ ,
280-
&tmfd, false/* changingPart */ );
276+
result=table_tuple_delete(rel,tid,
277+
GetCurrentCommandId(true),
278+
snapshot,InvalidSnapshot,
279+
true/* wait for commit */ ,
280+
&tmfd, false/* changingPart */ );
281281

282282
switch (result)
283283
{
@@ -299,34 +299,34 @@ simple_table_delete(Relation rel, ItemPointer tid, Snapshot snapshot)
299299
break;
300300

301301
default:
302-
elog(ERROR,"unrecognizedtable_delete status: %u",result);
302+
elog(ERROR,"unrecognizedtable_tuple_delete status: %u",result);
303303
break;
304304
}
305305
}
306306

307307
/*
308-
*simple_table_update - replace a tuple
308+
*simple_table_tuple_update - replace a tuple
309309
*
310310
* This routine may be used to update a tuple when concurrent updates of
311311
* the target tuple are not expected (for example, because we have a lock
312312
* on the relation associated with the tuple). Any failure is reported
313313
* via ereport().
314314
*/
315315
void
316-
simple_table_update(Relationrel,ItemPointerotid,
317-
TupleTableSlot*slot,
318-
Snapshotsnapshot,
319-
bool*update_indexes)
316+
simple_table_tuple_update(Relationrel,ItemPointerotid,
317+
TupleTableSlot*slot,
318+
Snapshotsnapshot,
319+
bool*update_indexes)
320320
{
321321
TM_Resultresult;
322322
TM_FailureDatatmfd;
323323
LockTupleModelockmode;
324324

325-
result=table_update(rel,otid,slot,
326-
GetCurrentCommandId(true),
327-
snapshot,InvalidSnapshot,
328-
true/* wait for commit */ ,
329-
&tmfd,&lockmode,update_indexes);
325+
result=table_tuple_update(rel,otid,slot,
326+
GetCurrentCommandId(true),
327+
snapshot,InvalidSnapshot,
328+
true/* wait for commit */ ,
329+
&tmfd,&lockmode,update_indexes);
330330

331331
switch (result)
332332
{
@@ -348,7 +348,7 @@ simple_table_update(Relation rel, ItemPointer otid,
348348
break;
349349

350350
default:
351-
elog(ERROR,"unrecognizedtable_update status: %u",result);
351+
elog(ERROR,"unrecognizedtable_tuple_update status: %u",result);
352352
break;
353353
}
354354

‎src/backend/commands/copy.c‎

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ typedef enum EolType
9090
*/
9191
typedefenumCopyInsertMethod
9292
{
93-
CIM_SINGLE,/* usetable_insert or fdw routine */
93+
CIM_SINGLE,/* usetable_tuple_insert or fdw routine */
9494
CIM_MULTI,/* always use table_multi_insert */
9595
CIM_MULTI_CONDITIONAL/* use table_multi_insert only if valid */
9696
}CopyInsertMethod;
@@ -2664,7 +2664,7 @@ CopyFrom(CopyState cstate)
26642664
PartitionTupleRouting*proute=NULL;
26652665
ErrorContextCallbackerrcallback;
26662666
CommandIdmycid=GetCurrentCommandId(true);
2667-
intti_options=0;/* start with defaulttable_insertoptions */
2667+
intti_options=0;/* start with default options for insert */
26682668
BulkInsertStatebistate=NULL;
26692669
CopyInsertMethodinsertMethod;
26702670
CopyMultiInsertInfomultiInsertInfo= {0};/* pacify compiler */
@@ -2737,11 +2737,11 @@ CopyFrom(CopyState cstate)
27372737
* FSM for free space is a waste of time, even if we must use WAL because
27382738
* of archiving. This could possibly be wrong, but it's unlikely.
27392739
*
2740-
* The comments fortable_insert and RelationGetBufferForTuple specify that
2741-
* skipping WAL logging is only safe if we ensure that our tuples do not
2742-
* go into pages containing tuples from any other transactions --- but this
2743-
* must be the case if we have a new table or new relfilenode, so we need
2744-
* no additional work to enforce that.
2740+
* The comments fortable_tuple_insert and RelationGetBufferForTuple
2741+
*specify thatskipping WAL logging is only safe if we ensure that our
2742+
*tuples do notgo into pages containing tuples from any other
2743+
*transactions --- but thismust be the case if we have a new table or
2744+
*new relfilenode, so we needno additional work to enforce that.
27452745
*
27462746
* We currently don't support this optimization if the COPY target is a
27472747
* partitioned table as we currently only lazily initialize partition
@@ -2888,9 +2888,9 @@ CopyFrom(CopyState cstate)
28882888
/*
28892889
* It's generally more efficient to prepare a bunch of tuples for
28902890
* insertion, and insert them in one table_multi_insert() call, than call
2891-
*table_insert() separately for every tuple. However, there are a number
2892-
* of reasons why we might not be able to do this. These are explained
2893-
* below.
2891+
*table_tuple_insert() separately for every tuple. However, there are a
2892+
*numberof reasons why we might not be able to do this. These are
2893+
*explainedbelow.
28942894
*/
28952895
if (resultRelInfo->ri_TrigDesc!=NULL&&
28962896
(resultRelInfo->ri_TrigDesc->trig_insert_before_row||
@@ -3286,8 +3286,8 @@ CopyFrom(CopyState cstate)
32863286
else
32873287
{
32883288
/* OK, store the tuple and create index entries for it */
3289-
table_insert(resultRelInfo->ri_RelationDesc,myslot,
3290-
mycid,ti_options,bistate);
3289+
table_tuple_insert(resultRelInfo->ri_RelationDesc,
3290+
myslot,mycid,ti_options,bistate);
32913291

32923292
if (resultRelInfo->ri_NumIndices>0)
32933293
recheckIndexes=ExecInsertIndexTuples(myslot,

‎src/backend/commands/createas.c‎

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -60,7 +60,7 @@ typedef struct
6060
Relationrel;/* relation to write to */
6161
ObjectAddressreladdr;/* address of rel, for ExecCreateTableAs */
6262
CommandIdoutput_cid;/* cmin to insert in output tuples */
63-
intti_options;/*table_insert performance options */
63+
intti_options;/*table_tuple_insert performance options */
6464
BulkInsertStatebistate;/* bulk insert state */
6565
}DR_intorel;
6666

@@ -576,18 +576,18 @@ intorel_receive(TupleTableSlot *slot, DestReceiver *self)
576576

577577
/*
578578
* Note that the input slot might not be of the type of the target
579-
* relation. That's supported bytable_insert(), but slightly less
579+
* relation. That's supported bytable_tuple_insert(), but slightly less
580580
* efficient than inserting with the right slot - but the alternative
581581
* would be to copy into a slot of the right type, which would not be
582582
* cheap either. This also doesn't allow accessing per-AM data (say a
583583
* tuple's xmin), but since we don't do that here...
584584
*/
585585

586-
table_insert(myState->rel,
587-
slot,
588-
myState->output_cid,
589-
myState->ti_options,
590-
myState->bistate);
586+
table_tuple_insert(myState->rel,
587+
slot,
588+
myState->output_cid,
589+
myState->ti_options,
590+
myState->bistate);
591591

592592
/* We know this is a newly created relation, so there are no indexes */
593593

‎src/backend/commands/matview.c‎

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,7 @@ typedef struct
5454
/* These fields are filled by transientrel_startup: */
5555
Relationtransientrel;/* relation to write to */
5656
CommandIdoutput_cid;/* cmin to insert in output tuples */
57-
intti_options;/*table_insert performance options */
57+
intti_options;/*table_tuple_insert performance options */
5858
BulkInsertStatebistate;/* bulk insert state */
5959
}DR_transientrel;
6060

@@ -481,18 +481,18 @@ transientrel_receive(TupleTableSlot *slot, DestReceiver *self)
481481

482482
/*
483483
* Note that the input slot might not be of the type of the target
484-
* relation. That's supported bytable_insert(), but slightly less
484+
* relation. That's supported bytable_tuple_insert(), but slightly less
485485
* efficient than inserting with the right slot - but the alternative
486486
* would be to copy into a slot of the right type, which would not be
487487
* cheap either. This also doesn't allow accessing per-AM data (say a
488488
* tuple's xmin), but since we don't do that here...
489489
*/
490490

491-
table_insert(myState->transientrel,
492-
slot,
493-
myState->output_cid,
494-
myState->ti_options,
495-
myState->bistate);
491+
table_tuple_insert(myState->transientrel,
492+
slot,
493+
myState->output_cid,
494+
myState->ti_options,
495+
myState->bistate);
496496

497497
/* We know this is a newly created relation, so there are no indexes */
498498

‎src/backend/commands/tablecmds.c‎

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -4732,9 +4732,9 @@ ATRewriteTable(AlteredTableInfo *tab, Oid OIDNewHeap, LOCKMODE lockmode)
47324732
newrel = NULL;
47334733

47344734
/*
4735-
* Prepare a BulkInsertState and options fortable_insert. Because we're
4736-
* building a new heap, we can skip WAL-logging and fsync it to disk at
4737-
* the end instead (unless WAL-logging is required for archiving or
4735+
* Prepare a BulkInsertState and options fortable_tuple_insert. Because
4736+
*we'rebuilding a new heap, we can skip WAL-logging and fsync it to disk
4737+
*atthe end instead (unless WAL-logging is required for archiving or
47384738
* streaming replication). The FSM is empty too, so don't bother using it.
47394739
*/
47404740
if (newrel)
@@ -5005,7 +5005,8 @@ ATRewriteTable(AlteredTableInfo *tab, Oid OIDNewHeap, LOCKMODE lockmode)
50055005

50065006
/* Write the tuple out to the new relation */
50075007
if (newrel)
5008-
table_insert(newrel, insertslot, mycid, ti_options, bistate);
5008+
table_tuple_insert(newrel, insertslot, mycid,
5009+
ti_options, bistate);
50095010

50105011
ResetExprContext(econtext);
50115012

‎src/backend/commands/trigger.c‎

Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -3332,7 +3332,7 @@ GetTupleForTrigger(EState *estate,
33323332
*/
33333333
if (!IsolationUsesXactSnapshot())
33343334
lockflags |=TUPLE_LOCK_FLAG_FIND_LAST_VERSION;
3335-
test=table_lock_tuple(relation,tid,estate->es_snapshot,oldslot,
3335+
test=table_tuple_lock(relation,tid,estate->es_snapshot,oldslot,
33363336
estate->es_output_cid,
33373337
lockmode,LockWaitBlock,
33383338
lockflags,
@@ -3386,7 +3386,7 @@ GetTupleForTrigger(EState *estate,
33863386
ereport(ERROR,
33873387
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
33883388
errmsg("could not serialize access due to concurrent update")));
3389-
elog(ERROR,"unexpectedtable_lock_tuple status: %u",test);
3389+
elog(ERROR,"unexpectedtable_tuple_lock status: %u",test);
33903390
break;
33913391

33923392
caseTM_Deleted:
@@ -3402,7 +3402,7 @@ GetTupleForTrigger(EState *estate,
34023402
break;
34033403

34043404
default:
3405-
elog(ERROR,"unrecognizedtable_lock_tuple status: %u",test);
3405+
elog(ERROR,"unrecognizedtable_tuple_lock status: %u",test);
34063406
return false;/* keep compiler quiet */
34073407
}
34083408
}
@@ -3412,7 +3412,8 @@ GetTupleForTrigger(EState *estate,
34123412
* We expect the tuple to be present, thus very simple error handling
34133413
* suffices.
34143414
*/
3415-
if (!table_fetch_row_version(relation,tid,SnapshotAny,oldslot))
3415+
if (!table_tuple_fetch_row_version(relation,tid,SnapshotAny,
3416+
oldslot))
34163417
elog(ERROR,"failed to fetch tuple for trigger");
34173418
}
34183419

@@ -4270,7 +4271,9 @@ AfterTriggerExecute(EState *estate,
42704271
{
42714272
LocTriggerData.tg_trigslot=ExecGetTriggerOldSlot(estate,relInfo);
42724273

4273-
if (!table_fetch_row_version(rel,&(event->ate_ctid1),SnapshotAny,LocTriggerData.tg_trigslot))
4274+
if (!table_tuple_fetch_row_version(rel,&(event->ate_ctid1),
4275+
SnapshotAny,
4276+
LocTriggerData.tg_trigslot))
42744277
elog(ERROR,"failed to fetch tuple1 for AFTER trigger");
42754278
LocTriggerData.tg_trigtuple=
42764279
ExecFetchSlotHeapTuple(LocTriggerData.tg_trigslot, false,&should_free_trig);
@@ -4287,7 +4290,9 @@ AfterTriggerExecute(EState *estate,
42874290
{
42884291
LocTriggerData.tg_newslot=ExecGetTriggerNewSlot(estate,relInfo);
42894292

4290-
if (!table_fetch_row_version(rel,&(event->ate_ctid2),SnapshotAny,LocTriggerData.tg_newslot))
4293+
if (!table_tuple_fetch_row_version(rel,&(event->ate_ctid2),
4294+
SnapshotAny,
4295+
LocTriggerData.tg_newslot))
42914296
elog(ERROR,"failed to fetch tuple2 for AFTER trigger");
42924297
LocTriggerData.tg_newtuple=
42934298
ExecFetchSlotHeapTuple(LocTriggerData.tg_newslot, false,&should_free_new);

‎src/backend/executor/execMain.c‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2436,7 +2436,7 @@ ExecBuildAuxRowMark(ExecRowMark *erm, List *targetlist)
24362436
* quals. For that result to be useful, typically the input tuple has to be
24372437
* last row version (otherwise the result isn't particularly useful) and
24382438
* locked (otherwise the result might be out of date). That's typically
2439-
* achieved by usingtable_lock_tuple() with the
2439+
* achieved by usingtable_tuple_lock() with the
24402440
* TUPLE_LOCK_FLAG_FIND_LAST_VERSION flag.
24412441
*
24422442
* Returns a slot containing the new candidate update/delete tuple, or
@@ -2654,9 +2654,9 @@ EvalPlanQualFetchRowMarks(EPQState *epqstate)
26542654
else
26552655
{
26562656
/* ordinary table, fetch the tuple */
2657-
if (!table_fetch_row_version(erm->relation,
2658-
(ItemPointer)DatumGetPointer(datum),
2659-
SnapshotAny,slot))
2657+
if (!table_tuple_fetch_row_version(erm->relation,
2658+
(ItemPointer)DatumGetPointer(datum),
2659+
SnapshotAny,slot))
26602660
elog(ERROR,"failed to fetch tuple for EvalPlanQual recheck");
26612661
}
26622662
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp