Re: Inconsistency between table am callback and table function names

Hi,

On 2019-05-08 17:05:07 -0700, Ashwin Agrawal wrote:
> On Wed, May 8, 2019 at 2:51 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2019-05-08 00:32:22 -0700, Ashwin Agrawal wrote:
> > > The general theme for table function names seem to be
> > > "table_<am_callback_name>". For example table_scan_getnextslot() and its
> > > corresponding callback scan_getnextslot(). Most of the table functions and
> > > callbacks follow mentioned convention except following ones
> > >
> > > table_beginscan
> > > table_endscan
> > > table_rescan
> > > table_fetch_row_version
> > > table_get_latest_tid
> > > table_insert
> > > table_insert_speculative
> > > table_complete_speculative
> > > table_delete
> > > table_update
> > > table_lock_tuple
> > >
> > > the corresponding callback names for them are
> > >
> > > scan_begin
> > > scan_end
> > > scan_rescan
> >
> > The mismatch here is just due of backward compat with the existing
> > function names.
>
> I am missing something here, would like to know more. table_ seem all
> new fresh naming. Hence IMO having consistency with surrounding and
> related code carries more weight as I don't know backward compat
> serving what purpose. Heap function names can continue to call with
> same old names for backward compat if required.

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.

Greetings,

Andres Freund