Re: Inconsistency between table am callback and table function names

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inconsistency between table am callback and table function names
Date: 2019-05-13 19:50:56
Message-ID: CA+TgmoanUyKyKdp-gPUYyd8Htjpb2-eJjqZNGYZdM2sJVB=_6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Amell 2019-05-13 19:52:15 Quitting the thes
Previous Message Peter Eisentraut 2019-05-13 19:50:34 Re: PostgreSQL 12: Feature Highlights