From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: a way forward on bootstrap data |
Date: | 2018-04-07 13:56:44 |
Message-ID: | 816.1523109404@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> John Naylor wrote:
>> Commit 9fdb675fc added a symbol to pg_opfamily.h
>> where there were none before, so I went ahead and wrapped it with an
>> EXPOSE_TO_CLIENT_CODE macro.
> Actually, after pushing that, I was thinking maybe it's better to remove
> that #define from there and put it in each of the two .c files that need
> it. I don't think it makes sense to expose this macro any further, and
> before that commit it was localized to a single file.
We're speaking of IsBooleanOpfamily, right? Think I'd leave it where it
is. As soon as you have more than one place using a macro like that,
there's room for maintenance mistakes.
Now it could also be argued that indxpath.c and partprune.c don't
necessarily have the same idea of "boolean opfamily" anyway, in which case
giving them separate copies might be better. Not sure about that.
Anyway, now that John and I have each (separately) rebased the bootstrap
patch over that, I'd appreciate it if you hold off cosmetic refactoring
till said patch goes in, which I expect to do in ~ 24 hours.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2018-04-07 14:10:44 | Re: [HACKERS] [PATCH] Incremental sort |
Previous Message | Alexander Korotkov | 2018-04-07 13:56:07 | Re: [HACKERS] [PATCH] Incremental sort |