Wow, that is a big patch.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Fabien COELHO wrote:
Content-Description:

[ Attachment, skipping... ]

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Bruce Momjian wrote:
ISTM that this version still does not allow building contrib without
having installed pg_config first. That is a no-no.


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
Sounds like the list of objections is getting shorter anyway ;-). Do
you feel that this patch is going in basically the right direction?
I've not had any time to look at it myself ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Dear Peter,



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 (AT) cri (DOT) ensmp.fr

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Fabien COELHO wrote:
OK, I think we're getting somewhere.

I am still opposed to adding more targets of the form "light-install",
"client-only install", etc. Please discuss this on -hackers. It can
be done as a separate patch later on if need be.

While I now understand what you are doing in contrib, I ask who is going
to want to maintain two parallel sets of makefiles, one for PGXS and
one for in-tree builds? One who is going to want to use the PGXS ones
anyway? I realize they're good examples, but examples should be put
into the documentation, so people can find them.

Paste your documentation (pgxs.sgml) somewhere into xfunc.sgml, where it
discusses writing user-defined functions. This material isn't long
enough to warrant a chapter of its own.

+ ifdef PGXS
+ LDFLAGS += -L$(pkglibdir)
+ endif

needs to disappear. There is nothing to link with in there. (If there
is, that's a bug.)

libpgport should be installed in the normal libdir.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Dear Peter,


It is a renaming of the previous 'install' target, as the new install is
the previous 'server-install', so it is no different from the current
status.

I let 'light-install' as a compromise wrt Tom view that the default
installation should not include header files, so that it would be still
easy to do that...

Ok, as you wish. I just felt it was easy and useful.

Ok.

Yep, that is indeed a good point.

Well, I've been disappointed in the past when I wanted to test a contrib
and had to reconfigure everything to do so. So I really think it is useful
to be able to add contribs as an after-thought.

I really tend to think that there could be the pgxs only version, but that
would break "compile without installing", and you don't want that, as
previously discussed.

So there is no perfect solution:-(

What I can do is to enable the current makefiles to use pgxs if desired by
the user, maybe with some switch, say "make install" vs "make USE_PGXS=yes
install"... I'll lose the clean illustration part but would have one
makefile only and still enable using pgxs if needed.


Humm.

Ok.

I think I added it because it did not work without that, but I can recheck
whether it is really needed.

Ok.

I'll submit a new patch on tomorrow to hopefully address all these issues.
Thanks a lot for all these comments,

have a nice day,

--
Fabien Coelho - coelho (AT) cri (DOT) ensmp.fr

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Patch withdrawn by author.

---------------------------------------------------------------------------

Fabien COELHO wrote:
Content-Description:

[ Attachment, skipping... ]

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly