On 3/11/15 10:00 AM, Andres Freund wrote:
> On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
>> I don't think we care one bit whether these modules use pgxs, at least
>> not currently. If we find any issues later on, it should be an easy fix
>> anyway.
>
> I personally find it quite ugly to use pgxs for stuff in
> src/bin. pgxs.mk says:
> # This file contains generic rules to build many kinds of simple
> # extension modules. You only need to set a few variables and include
> # this file, the rest will be done here.
Let's get history straight. pgxs was not initially an external
extension building framework. It was a refactoring of our own internal
makefile rules, because a lot of code under contrib had the same rules
copy-and-pasted. It was only much later that it was rebranded for
external use. It's debatable why it wasn't expanded to also be used in
src/bin/, but I attribute that to a combination of boredom, complicated
special cases under src/bin/, less frequent additions under src/bin/,
and said rebranding -- not because it would have been a bad idea.
You effectively suggest that we are not allowed to use our own code and
propose that we undo that refactoring, and then what? I'll just
resubmit the same patch from 2001 to refactor it again?
> I don't object at all to introducing more generic rules for src/bin, but
> that seems like a separate task. And one that should be done right not
> just use some convenient hack. And you can't tell me that
> +NO_PGXS = 1
> +include $(top_srcdir)/src/makefiles/pgxs.mk
> isn't a hack...
Well, that's unfortunate, but I'd rather live with one line of hack for
a while that I can easily fix later, instead of writing completely new
makefiles from scratch. Who is going to want to debug those, by the
way? The turnaround time for makefile changes in this project is one
month per line, because we can't get anything reviewed across all
platforms any faster.