diff options
author | Andres Freund <andres@anarazel.de> | 2019-05-23 16:25:48 -0700 |
---|---|---|
committer | Andres Freund <andres@anarazel.de> | 2019-05-23 16:32:36 -0700 |
commit | 73b8c3bd2889fed986044e15aefd0911f96ccdd3 (patch) | |
tree | 8fcd867ac811feecc99ed5f645088b73c44d5051 /src/backend/executor/nodeLockRows.c | |
parent | 54487d1560619a0027e0651d1b8d715ca8fc388c (diff) | |
download | postgresql-73b8c3bd2889fed986044e15aefd0911f96ccdd3.tar.gz postgresql-73b8c3bd2889fed986044e15aefd0911f96ccdd3.zip |
tableam: Rename wrapper functions to match callback names.
Some of the wrapper functions didn't match the callback names. Many of
them due to staying "consistent" with historic naming of the wrapped
functionality. We decided that for most cases it's more important to
be for tableam to be consistent going forward, than with the past.
The one exception is beginscan/endscan/... because it'd have looked
odd to have systable_beginscan/endscan/... with a different naming
scheme, and changing the systable_* APIs would have caused way too
much churn (including breaking a lot of external users).
Author: Ashwin Agrawal, with some small additions by Andres Freund
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com
Diffstat (limited to 'src/backend/executor/nodeLockRows.c')
-rw-r--r-- | src/backend/executor/nodeLockRows.c | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/backend/executor/nodeLockRows.c b/src/backend/executor/nodeLockRows.c index 4067554ed94..41513ceec65 100644 --- a/src/backend/executor/nodeLockRows.c +++ b/src/backend/executor/nodeLockRows.c @@ -185,7 +185,7 @@ lnext: if (!IsolationUsesXactSnapshot()) lockflags |= TUPLE_LOCK_FLAG_FIND_LAST_VERSION; - test = table_lock_tuple(erm->relation, &tid, estate->es_snapshot, + test = table_tuple_lock(erm->relation, &tid, estate->es_snapshot, markSlot, estate->es_output_cid, lockmode, erm->waitPolicy, lockflags, @@ -208,7 +208,7 @@ lnext: * to fetch the updated tuple instead, but doing so would * require changing heap_update and heap_delete to not * complain about updating "invisible" tuples, which seems - * pretty scary (table_lock_tuple will not complain, but few + * pretty scary (table_tuple_lock will not complain, but few * callers expect TM_Invisible, and we're not one of them). So * for now, treat the tuple as deleted and do not process. */ @@ -229,7 +229,7 @@ lnext: ereport(ERROR, (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE), errmsg("could not serialize access due to concurrent update"))); - elog(ERROR, "unexpected table_lock_tuple status: %u", + elog(ERROR, "unexpected table_tuple_lock status: %u", test); break; @@ -246,7 +246,7 @@ lnext: break; default: - elog(ERROR, "unrecognized table_lock_tuple status: %u", + elog(ERROR, "unrecognized table_tuple_lock status: %u", test); } |