Re: Inconsistency between table am callback and table function names

On Mon, May 13, 2019 at 12:51 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, May 10, 2019 at 3:43 PM Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
> wrote:
> > 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
> > table_insert -> table_tuple_insert
> > table_insert_speculative -> table_tuple_insert_speculative
> > table_delete -> table_tuple_delete
> > table_update -> table_tuple_update
> > table_lock_tuple -> table_tuple_lock
> >
> > 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.
>
> I vote to rename all the ones where the new name would contain "tuple"
> and to leave the others alone. i.e. leave table_beginscan,
> table_endscan, and table_rescan as they are. I think that there's
> little benefit in standardizing table_rescan but not the other two,
> and we seem to agree that tinkering with the other two gets into a
> painful amount of churn.
>

Thank you. Please find the patch to rename the agreed functions. It would
be good to make all consistent instead of applying exception to three
functions but seems no consensus on it. Given table_ api are new, we could
modify them leaving systable_ ones as is, but as objections left that as is.