Re: Inconsistency between table am callback and table function names - Mailing list pgsql-hackers

From Ashwin Agrawal
Subject Re: Inconsistency between table am callback and table function names
Date
Msg-id CALfoeivcJaa33Hr8NQ-k0vdw0kbiEFV0-H90r-4FMqkPh3mmxQ@mail.gmail.com
Whole thread Raw
In response to Re: Inconsistency between table am callback and table function names  (Andres Freund <andres@anarazel.de>)
Responses Re: Inconsistency between table am callback and table function names
Re: Inconsistency between table am callback and table function names
List pgsql-hackers
On Fri, May 10, 2019 at 10:51 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2019-05-10 10:43:44 -0700, Ashwin Agrawal wrote:
> > On Thu, May 9, 2019 at 8:52 AM Andres Freund <andres@anarazel.de> wrote:
> > > The changes necessary for tableam were already huge. Changing naming
> > > schemes for functions that are used all over the backend (e.g. ~80 calls
> > > to table_beginscan), and where there's other wrapper functions that also
> > > widely used (237 calls to systable_beginscan) which didn't have to be
> > > touched, at the same time would have made it even harder to review.
> >
> > If there are no objections to renaming now, as separate independent
> > patch, I am happy to do the same and send it across. Will rename to
> > make it consistent as mentioned at start of the thread leaving
> > table_relation_xxx() ones as is today.
>
> What would you want to rename precisely? Don't think it's useful to
> start sending patches before we agree on something concrete.  I'm not on
> board with patching hundreds systable_beginscan calls (that'll break a
> lot of external code, besides the churn of in-core code), nor with the
> APIs around that having a diverging name scheme.

Meant to stick the question mark in that email, somehow missed. Yes
not planning to spend any time on it if objections. Here is the list
of renames I wish to perform.

Lets start with low hanging ones.

table_rescan -> table_scan_rescan
git grep table_rescan | wc -l
6

table_insert -> table_tuple_insert
git grep tuple_insert | wc -l
13

table_insert_speculative -> table_tuple_insert_speculative
git grep tuple_insert_speculative | wc -l
5

table_delete -> table_tuple_delete (table_delete reads incorrect as
not deleting the table)
git grep tuple_delete | wc -l
8

table_update -> table_tuple_update
git grep tuple_update | wc -l
5

table_lock_tuple -> table_tuple_lock
git grep tuple_lock | wc -l
26


Below two you already mentioned no objections to rename
table_fetch_row_version -> table_tuple_fetch_row_version
table_get_latest_tid -> table_tuple_get_latest_tid


Now, table_beginscan and table_endscan are the ones which are
wide-spread. Desire seems we should keep it consistent with
systable_beginscan. Understand the constraints and churn aspect, given
that diverging naming scheme is unavoidable. Why not leave
systable_beginscan as it is and only rename table_beginscan and its
counterparts table_beginscan_xxx() atleast?

Index interfaces and table interfaces have some diverged naming scheme
already like index_getnext_slot and table_scan_getnextslot. Not
proposing to change them. But at least reducing wherever possible
sooner would be helpful.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is infinite_recurse test suddenly failing?
Next
From: Tom Lane
Date:
Subject: Re: What's the point of allow_system_table_mods?