Re: build infrastructure for extensions v3 - Mailing list pgsql-patches

Dear Peter,


> ISTM that this version still does not allow building contrib without
> having installed pg_config first.


This version DOES allow building contrib without having installed
pg_config first. Indeed, I did not remove the previous infrastructure;-)

I play a little bit on words, but it is a fact anyway. With the submitted
patch, you just need to type "make" to compile contrib as usual!


(1) The main aim of the infrastructure is not for contribs but for
external modules. There is not such issue for external add-ons.
I preliminarily provided the contrib makefiles as "how to" examples.


(2) What the patch adds is the ability to ALSO install a contrib as an
afterthought. It also enable external (non contrib) modules to rely on it
so they can be installed much more simply. You have to invoke
"make -f pgxs.mk" to do that, as the makefile is a little bit different.

So the issue would be relevant if the old makefiles were to be removed,
which is not the case with the submitted patch. If they were to be
removed, I also have an opinion at the time. I may be wrong, but this my
opinion nevertheless without further arguments:


(3) I think it is not a real issue. The argument you gave is "packagers
will need to compile contribs without installing postgresql first". My
point is that if they can do that with apache, they should survive with
postgresql just the same.

More specifically, I think that it is much better to be able to compile a
contrib or any external module without having to reconfigure the sources,
and even without needing to get them.

Now if you have other arguments, or that you can explain to me why this
fact is such an issue, I may change my point of view.


(4) I could fix the contrib pgxs makefiles so that they check for
something, like:

    PG := $(shell type pg_config 2> /dev/null)
    ifeq ($(PG),)
    # postgresql is not installed...
        else
        # postgresql is installed...
        endif

so what?

  1. Even if there is pg_config in the path, that would not
     necessarilly mean that the user want to compile with it.

  2. This would make the contrib pgxs makefiles different from
     what they are expected to be for external modules. I intended
     these makefiles as examples, and now they would be different from
     what is needed.

If you have a cool idea to make the original extension makefile to work in
any case without modification, I'm interested, because it would enable to
have both worlds and everybody would be happy!


(5) As a improvement to the submitted version, I could think of mixing the
current (contrib/contrib-global.mk) and (src/makefiles/pgxs.mk)  files so
that the core of the extension makefile is not replicated. But that would
not change the issue we're discussing.


So I'm still reserved about your reserves. Moreover I think that this
patch adds something and does not remove anything, and that it is
desirable to have an "extension infrastructure" for external modules in
the upcoming version, whether it is this one or anything else.
Although not perfect, this one is much better than nothing.


Anyway, if having a unique infrastructure is a definite blocking
constraint, I can implement (4) above, even if I think it is not such a
good idea.

So you decide. As I'll away during 3 weeks from July 19, it would be
better to decide quickly so that I can make the necessary changes before
leaving.


Have a nice day,

--
Fabien Coelho - coelho@cri.ensmp.fr