Re: What to name the current heap after pluggable storage / what to rename?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, 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-19 05:08:21
Message-ID: 20190319050821.kc4iwyos64jqw7rl@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-03-19 15:25:44 +1100, Haribabu Kommi wrote:
> On Tue, Mar 19, 2019 at 2:32 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I'm kinda wondering about replacing the TableTuple prefix with TableMod,
> > seems less confusing to me.

> One more way, how about just TupleUpdated and etc. Removing of Table?
> The structure name also suggests as TM (IMO, it is TupleModication?)

Enum members are in the global namespace. I could go for a TM_ prefix
however.

> I'm also wondering about replacing
> > *MayBeModified with *OK.

> How about TupleModified? I am fine with *OK also.

Hm, OK just seems nicer for lock_tuple, that's why I was wondering
about it, but I think my concern there is a bit pedantic.

> > Right now I have
> >
> > typedef enum TM_Result HTSU_Result;
> >
> > #define HeapTupleMayBeUpdated TableTupleMayBeModified
> > #define HeapTupleInvisible TableTupleInvisible
> > #define HeapTupleSelfUpdated TableTupleSelfModified
> > #define HeapTupleUpdated TableTupleUpdated
> > #define HeapTupleDeleted TableTupleDeleted
> > #define HeapTupleBeingUpdated TableTupleBeingModified
> > #define HeapTupleWouldBlock TableTupleWouldBlock
> >
> > in heapam.h (whereas the above is in tableam.h), for backward
> > compat. But I'm not sure it's worth it.
> >
>
> These old macros are pretty much used in the internal code, and I doubt
> that any one depends directly on those macros. I vote for removal of
> these backward compatibility macros.

Cool.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2019-03-19 05:22:33 Re: Add exclusive backup deprecation notes to documentation
Previous Message Chapman Flack 2019-03-19 04:59:03 Re: extensions are hitting the ceiling