Michael Paquier <michael.paqu...@gmail.com> writes:
> On Mon, Oct 13, 2014 at 10:04 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> No significant advantage will be gained by splitting it out and then
>> #including it; nobody's really going to fix their module builds until
>> they actually break.
>> On the general substance of the issue, our usual convention is that
>> src/backend/X/Y/Z.c has its prototypes in src/include/X/Z.h. If this
>> proposal moves us closer to that, I'm OK with enduring the module
>> breakage that will result. If, on the other hand, it in moves us
>> further away from that, then I'm against it.
> That's a 2/2 tie then AFAIK: Noah and Stephen express concerns about
> the breakage, you and I would be fine with a clear breakage to make
> code more organized (correct me if you don't feel this way).
FWIW, we break code *all the time* in the direction of requiring new
#include's. I think the argument that this particular case should
be sacrosanct is pretty thin. If we were back-patching then the
considerations would be different --- but as long as it's 9.5 material
I have no problem with it.
>> What I find strange about the actual patch is that it moves some but
>> not all of the prototypes for the stuff that ends up in quote.c into
>> quote.h. That doesn't seem right.
> Are you referring to the Datum quote_*(PG_FUNCTION_ARGS) that are
> still let in builtins.h? That was let on purpose to let all the SQL
> functions within builtins.h but I'd be happy to move everything to
> quote.h to make the separation clearer.
I agree with Robert on this one. builtins.h is really just a refuge
for declaring SQL-level functions that have no other natural home.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
