From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: What to name the current heap after pluggable storage / what to rename? |
Date: | 2019-03-13 00:39:03 |
Message-ID: | 20190313003903.nwvrxi7rw3ywhdel@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2018 at 11:17 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > The current pluggable table storage patchset [1] introduces the ability
> > to specify the access method of a table (CREATE TABLE ... USING
> > "ident"). The patchset currently names the current storage method
> > (i.e. heapam.c et al) "heap" (whereas e.g. zheap's in named, drumroll,
> > zheap).
>
> I vote for calling the current heap "heap" - i.e. what the patchset is
> currently doing. As others have already noted, that's a perfectly
> good word for storing stuff in no particular order, and it's also a
> term with a very long history. If we call it "oheap" or "pile" or
> something based on a clever pun, then we'll just be making users learn
> a new word for, as far as I can see, no real benefit.
>
> > Another would be to be aggressive in renaming, and deconflict by
> > renaming functions like heap_create[_with_catalog] etc to sound more
> > accurate. I think that has some appeal, because a lot of those names
> > aren't describing their tasks particularly well.
>
> I like that option.
In that vein, does anybody have an opinion about the naming of
a) HeapUpdateFailureData, which will be used for different AMs
b) HTSU_Result itself, which'll be the return parameter for
update/delete via tableam
c) Naming of HTSU_Result members (like HeapTupleBeingUpdated)
I can see us doing several things:
1) Live with the old names, explain the naming as historical baggage
2) Replace names, but add typedefs / #defines for backward compatibility
3) Rename without backward compatibility
If we were to go with 2) or 3), does anybody want to make a case for
renaming the HTSU_Result members? They've been confusing people for a
long while...
In the patch it's currently:
typedef enum
{
HeapTupleMayBeUpdated, /* or deleted */
HeapTupleInvisible,
HeapTupleSelfUpdated, /* or deleted */
HeapTupleUpdated,
HeapTupleDeleted,
HeapTupleBeingUpdated, /* or deleted */
HeapTupleWouldBlock /* can be returned by heap_tuple_lock */
} HTSU_Result;
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-03-13 00:39:54 | Re: Should we add GUCs to allow partition pruning to be disabled? |
Previous Message | Amit Langote | 2019-03-13 00:19:17 | Re: Update does not move row across foreign partitions in v11 |