Re: Inconsistency between table am callback and table function names
От | Robert Haas |
---|---|
Тема | Re: Inconsistency between table am callback and table function names |
Дата | |
Msg-id | CA+TgmoanUyKyKdp-gPUYyd8Htjpb2-eJjqZNGYZdM2sJVB=_6g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inconsistency between table am callback and table function names (Ashwin Agrawal <aagrawal@pivotal.io>) |
Ответы |
Re: Inconsistency between table am callback and table function names
|
Список | pgsql-hackers |
On Fri, May 10, 2019 at 3:43 PM Ashwin Agrawal <aagrawal@pivotal.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
В списке pgsql-hackers по дате отправления: