Re: still use IndexIsValid() etc. macros?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: still use IndexIsValid() etc. macros?
Date: 2018-12-18 22:08:32
Message-ID: 21791.1545170912@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> In another patch discussion it was brought up why the patch doesn't use
> the IndexIsValid() etc. macros.

> They are defined thus:

> /*
> * Use of these macros is recommended over direct examination of the state
> * flag columns where possible; this allows source code compatibility with
> * the hacky representation used in 9.2.
> */
> #define IndexIsValid(indexForm) ((indexForm)->indisvalid)
> #define IndexIsReady(indexForm) ((indexForm)->indisready)
> #define IndexIsLive(indexForm) ((indexForm)->indislive)

> I don't see them used consistently. Obviously, some low-level code
> needs to bypass them, but it's hard to see where to draw the line. Is
> it worth keeping these? Is there still code that maintains
> compatibility with 9.2 from a single source?

We have a general problem with people ignoring accessor macros;
it's hardly limited to these. The relcache accessor macros such as
RelationGetDescr, for instance, tend to get bypassed. I'm not sure
how worthwhile it is to be picky about that.

I agree that now that 9.2 is a year out of support, there's not
too much value in the original cross-branch-compatibility argument
for these particular macros.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-18 22:11:42 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Previous Message Peter Geoghegan 2018-12-18 22:02:37 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)