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
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) |