>> With the assumption that the above "that one" refered to the "PG_CONFIG"
>> macro definition in "Makefile.global". As existing extension makefiles do
>> not defined PG_CONFIG, relying on one would break them wrt future
>> releases?
>
> Ah, I see. I was thinking in terms of breaking them intentionally ;-)
Well, if that is what you want, is was perfect:-)
But ISTM that the remedy (breaking all past makefiles for all extensions)
is not worth the issue.
A better documentation, and possibly following your suggestion with an
explicit PG_CONFIG in contrib makefiles, but without breaking existing
extensions seems quite enough. The error made by Eddie is legitimate, but
it is also something rare, it did not come up in the last two years.
Please find attached a small patch which enhances the documentation on the
issue in my broken English.
> If we're worrying about cross-version compatibility then it seems there
> isn't any really nice way to make both combinations do the ideal thing.
> If someone has an updated module Makefile, ie,
>
> PG_CONFIG := pg_config
> PGXS := $(shell $(PG_CONFIG) --pgxs)
> include $(PGXS)
>
> then it will look like changing PG_CONFIG in the Makefile would work;
> but that will not work with an older PG release, because Makefile.global
> will override the value.
Okay, there are indeed two different compatibility issues : - "old" makefiles with possibly "new" pgxs conventions -
possibly"new" makefiles with "old" pgxs conventions
Indeed for "old" Makefile.global the PG_CONFIG is overwritten.
It would be okay if it is made clear that the PG_CONFIG macro MUST not be
updated from within the Makefile, but just from the commande line ?
Well that's still a little bit error prone anyway.
ISTM that the documentation update would suffice.
--
Fabien.
