[PATCH] Remove useless USE_PGXS support in contrib

On Jun 12, 2013, at 8:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

This has served no purpose except to

1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an example
4. break builds of PostgreSQL when users try to fix 3. by exporting USE_PGXS

There is adequate material in the documentation and elsewhere (PGXN) on
how to write extensions and their makefiles, so this is not needed.

+1 Nice.

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

----- Original Message -----

From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Cc:
Sent: Thursday, 13 June 2013 12:16 PM
Subject: [HACKERS] [PATCH] Remove useless USE_PGXS support in contrib

T his has served no purpose except to

1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an example
4. break builds of PostgreSQL when users try to fix 3. by exporting USE_PGXS

Agree, only if we consider these contrib module is always gonna deployed with the postgresql.
But, what if user going to install such module elsewhere i.e. not from contrib directory of pg source.
I this way Makefile should different, right? 

We need to makefile code should uniform to exclude any confusion to user.

if space is not such dominant, we can add code at the top of make file to avoid confusion of user to export USE_PGXS as follow  

ifndef USE_PGXS
top_builddir = ../..
makefile_global = $(top_builddir)/src/Makefile.global
ifeq "$(wildcard $(makefile_global))" ""
USE_PGXS = 1 
endif

/* remaining code as it is */*

Regards,
Amul Sul

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 6/13/13 9:20 PM, amul sul wrote:

Agree, only if we consider these contrib module is always gonna deployed with the postgresql.
But, what if user going to install such module elsewhere i.e. not from contrib directory of pg source.

Why would anyone do that?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Jun 14, 2013 at 9:35 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 6/13/13 9:20 PM, amul sul wrote:

Agree, only if we consider these contrib module is always gonna deployed with the postgresql.
But, what if user going to install such module elsewhere i.e. not from contrib directory of pg source.

Why would anyone do that?

Is he probably saying "install such module *from* elsewhere"? Like
directly from the source directory of a module using something like
following:

cd /path/to/module-source
make USE_PGXS=1 PG_CONFIG=/path/to/pg_config
make USE_PGXS=1 PG_CONFIG=/path/to/pg_config install

When user does not work with pg source directly and does not have
postgresql-contrib installed?
Am I missing something here?

--
Amit Langote

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/14/2013 08:35 AM, Peter Eisentraut wrote:

On 6/13/13 9:20 PM, amul sul wrote:

Agree, only if we consider these contrib module is always gonna deployed with the postgresql.
But, what if user going to install such module elsewhere i.e. not from contrib directory of pg source.

Why would anyone do that?

Maybe they wouldn't.

I do think we need to make sure that we have at least buildfarm coverage
of pgxs module building and testing. I have some coverage of a few
extensions I have written, which exercise that, so maybe that will
suffice. If not, maybe we need to have one module that only builds via
pgxs and is build after an install (i.e. not via the standard contrib
build).

I don't really like the directory layout we use for these modules
anyway, so I'm not sure they constitute best practice for extension
builders. Lately I have been using an extension skeleton that looks
something like this:

License
Readme.md
META.json (for pgxn)
extension.control
Makefile
doc/extension.md (soft linked to ../Readme.md)
src/extension.c
sql/extension.sql
test/sql/extension.sql
test/expected/extension.out

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/13/2013 11:16 AM, Peter Eisentraut wrote:

This has served no purpose except to

1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an example
4. break builds of PostgreSQL when users try to fix 3. by exporting USE_PGXS

Weak -1 from me; I find being able to build contrib modules using PGXS
from the source tree extremely useful in development. It allows me to
easily install an extension from a newer Pg version into an older
server, test against older servers, etc.

What about assuming USE_PGXS=1 if it's unset, and have recursive make
set USE_PGXS=0 explicitly when invoking contrib makefiles?

There'd be a behaviour change, in that you'd have to write USE_PGXS=0
when you wanted the module to build against the tree it was currently in
instead of with pgxs. Maybe that's just as confusing.

If everyone hates that idea I can just write a 'pgxs' command that
copies the Makefile, hacks it to use PGXS, and runs it, so it's not like
I lose anything critical.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> a écrit :

On 06/14/2013 08:35 AM, Peter Eisentraut wrote:

On 6/13/13 9:20 PM, amul sul wrote:

Agree, only if we consider these contrib module is always gonna

deployed with the postgresql.

But, what if user going to install such module elsewhere i.e. not

from contrib directory of pg source.

Why would anyone do that?

Maybe they wouldn't.

I do think we need to make sure that we have at least buildfarm
coverage
of pgxs module building and testing. I have some coverage of a few
extensions I have written, which exercise that, so maybe that will
suffice. If not, maybe we need to have one module that only builds via
pgxs and is build after an install (i.e. not via the standard contrib
build).

I agree, I found very useful to have all the provided extensions build with PGXS to debug it.
It also offers a good set of natural regression tests.

I don't really like the directory layout we use for these modules
anyway, so I'm not sure they constitute best practice for extension
builders. Lately I have been using an extension skeleton that looks
something like this:

License
Readme.md
META.json (for pgxn)
extension.control
Makefile
doc/extension.md (soft linked to ../Readme.md)

This makes mandatory to have a MODULEDIR defined or a rule to rename it with the extension name suffixed.

src/extension.c
sql/extension.sql

It is (was) the default place for regression tests....I am not sure it is a good thing to shuffle that.
Also, you don't do 'c/source.c'

--
Envoyé de mon téléphone, excusez la brièveté.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/15/2013 06:24 AM, Cédric Villemain wrote:

Andrew Dunstan <andrew@dunslane.net> a écrit :

On 06/14/2013 08:35 AM, Peter Eisentraut wrote:

On 6/13/13 9:20 PM, amul sul wrote:

Agree, only if we consider these contrib module is always gonna

deployed with the postgresql.

But, what if user going to install such module elsewhere i.e. not

from contrib directory of pg source.

Why would anyone do that?

Maybe they wouldn't.

I do think we need to make sure that we have at least buildfarm
coverage
of pgxs module building and testing. I have some coverage of a few
extensions I have written, which exercise that, so maybe that will
suffice. If not, maybe we need to have one module that only builds via
pgxs and is build after an install (i.e. not via the standard contrib
build).

I agree, I found very useful to have all the provided extensions build with PGXS to debug it.
It also offers a good set of natural regression tests.

I don't really like the directory layout we use for these modules
anyway, so I'm not sure they constitute best practice for extension
builders. Lately I have been using an extension skeleton that looks
something like this:

License
Readme.md
META.json (for pgxn)
extension.control
Makefile
doc/extension.md (soft linked to ../Readme.md)

This makes mandatory to have a MODULEDIR defined or a rule to rename it with the extension name suffixed.

Of course, for extension foo this would actually be foo.md. It installs
just fine like that. The makefile template has:

DOCS = $(wildcard doc/*.md)

src/extension.c
sql/extension.sql

It is (was) the default place for regression tests....I am not sure it is a good thing to shuffle that.
Also, you don't do 'c/source.c'

The sql here is the sql to install the extension, not part of the build
nor part of the tests.

Some time ago I fixed pg_regress to honor --inputdir and --outputdir
properly, so my Makefile template has this:

REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/

That keeps the testing stuff out of the way quite nicely.

You might not like this pattern, but I find it much saner that what we
currently use. I certainly don't claim it's perfect.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I don't really like the directory layout we use for these modules
anyway, so I'm not sure they constitute best practice for extension
builders. Lately I have been using an extension skeleton that looks

something like this:
License
Readme.md
META.json (for pgxn)
extension.control
Makefile
doc/extension.md (soft linked to ../Readme.md)

This makes mandatory to have a MODULEDIR defined or a rule to rename it
with the extension name suffixed.

Of course, for extension foo this would actually be foo.md. It installs
just fine like that. The makefile template has:

DOCS = $(wildcard doc/*.md)

Oh! yes, I missed the soft link.

src/extension.c
sql/extension.sql

It is (was) the default place for regression tests....I am not sure it is
a good thing to shuffle that. Also, you don't do 'c/source.c'

The sql here is the sql to install the extension, not part of the build
nor part of the tests.

I am interested by this topic, since we have Extensions we invite users to
increase the usage of them. So going a step forward with a better layout is
definitively something to do.

What do you suggest for the previous usage ? we have a hard rule to try to put
libdir in *sql.in files for example.

Some time ago I fixed pg_regress to honor --inputdir and --outputdir
properly, so my Makefile template has this:

REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/

That keeps the testing stuff out of the way quite nicely.

You might not like this pattern, but I find it much saner that what we
currently use. I certainly don't claim it's perfect.

I am interested by this topic, since we have Extensions we invite users to
increase the usage of them. So going a step forward with a better layout is
definitively something to do. I have no strong assumption on what the ideal
layout is, 'your' and pgxn layout are good and I won't vote against suggesting
to use them (and improve PGXS to match those suggestions).

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Craig Ringer wrote:

On 06/13/2013 11:16 AM, Peter Eisentraut wrote:

This has served no purpose except to

1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an example
4. break builds of PostgreSQL when users try to fix 3. by exporting USE_PGXS

Weak -1 from me; I find being able to build contrib modules using PGXS
from the source tree extremely useful in development. It allows me to
easily install an extension from a newer Pg version into an older
server, test against older servers, etc.

This use case seems too narrow to me to justify the burden of keeping
PGXS-enabled makefiles in contrib.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2013 11:28 AM, Alvaro Herrera wrote:

Craig Ringer wrote:

On 06/13/2013 11:16 AM, Peter Eisentraut wrote:

This has served no purpose except to

1. take up space 2. confuse users 3. produce broken external
extension modules that take contrib as an example 4. break
builds of PostgreSQL when users try to fix 3. by exporting
USE_PGXS

Weak -1 from me; I find being able to build contrib modules using
PGXS from the source tree extremely useful in development. It
allows me to easily install an extension from a newer Pg version
into an older server, test against older servers, etc.

This use case seems too narrow to me to justify the burden of
keeping PGXS-enabled makefiles in contrib.

What was the burden of it?

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRvLWLAAoJEDfy90M199hllqIP/3ZHKaiOEidUPoRK2n9BrW3b
MmHzfzn2rhOxhL4XYSxUz5mI8CDecYf5PXi1m0dwdyTCGUNWSQRiNMzN5x0Wd8v3
TVD2PS3m9XM4tWf+Y1DxSjkrDZ4KZFE8HdKFJUoCu73a0wS+nIerPC28PsPJjfen
bBzaWMbZsuY37GUh3uzJW4p/KDrRV5Bh298tP2hgWPCdxpenwT3sK7+qw2Goumly
Gdltp6BBkUTxpk42X72PRPx+QUwZJfmQ0QjubR+vkiYSi5otyVB2q1xr+umts+SW
Z69dfxyQIp0BHaFpUB1DFVXwx+hmWyNKWwA0mIBIXQhlKh8VZXbz5ENHKnK1xPpK
GcO/LFl/z5zI0CMFVFW2nwQPJ8NN+Jmru23Q53FGGsIXXJJJofCDt8U9BDLCGYpZ
uq1E1/7HfIkDL0f6jDRrBmdQacnRRYWKmhEGXjQQ1Med5IG3pFiqedZj3d8xCNDU
xB1wwAnIOiLnIo8WF2eIeYzuPQ5gN+xZFpUrQz+tt3UBuIsvhxXI1qQvJwRnwJTx
O30Aw7zZYbnI+zZvkO1ibyIUUp8byE0DuIBwg2ergKTD4BVpKi2ThIntSXY3W/hO
JzwulZfaQ120NBmrDXx641SnkXlRmMYK82KzJcDFMcyR6y04dZVhrUi0Ml2Yno6Z
dsi1AdDZJpBJq9nwIJ53
=fVLk
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jun 15, 2013, at 4:12 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/

That keeps the testing stuff out of the way quite nicely.

I don't suppose there could be a way for the makefile to notice the --outputdir option and add those files to the clean target itself, could there? Having it hard-coded is slightly annoying. Maybe it could ask pg_regress where to find them?

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/15/2013 02:43 PM, David E. Wheeler wrote:

On Jun 15, 2013, at 4:12 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/

That keeps the testing stuff out of the way quite nicely.

I don't suppose there could be a way for the makefile to notice the --outputdir option and add those files to the clean target itself, could there? Having it hard-coded is slightly annoying. Maybe it could ask pg_regress where to find them?

That doesn't sound like a promising line of development to me. Better
would be to provide a PGXS option to specify where tests are based, and
set the clean target accordingly.

Then instead of the above you'd just be able to say something like

MODULETEST = test
REGRESS_OPTS = --load-extension=$(EXTENSION)

Which would be a good deal cleaner.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le samedi 15 juin 2013 23:45:21, Andrew Dunstan a écrit :

On 06/15/2013 02:43 PM, David E. Wheeler wrote:

On Jun 15, 2013, at 4:12 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

REGRESS_OPTS = --inputdir=test --outputdir=test \

--load-extension=$(EXTENSION)

...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/

That keeps the testing stuff out of the way quite nicely.

I don't suppose there could be a way for the makefile to notice the
--outputdir option and add those files to the clean target itself, could
there? Having it hard-coded is slightly annoying. Maybe it could ask
pg_regress where to find them?

That doesn't sound like a promising line of development to me. Better
would be to provide a PGXS option to specify where tests are based, and
set the clean target accordingly.

Then instead of the above you'd just be able to say something like

MODULETEST = test

or REGRESSDIR ?

Also I suggest to remove the need to set REGRESS at all, and default to all
sql files in REGRESSDIR/sql (if REGRESSDIR is set)

Back to DOCS, we may also have PGXS default to find a README(.*) and rename it
to README.$extension.$1 if MODULEDIR is not set.

REGRESS_OPTS = --load-extension=$(EXTENSION)

Which would be a good deal cleaner.

yes.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Hi,

Peter Eisentraut <peter_e@gmx.net> writes:

2. confuse users
3. produce broken external extension modules that take contrib as an example

I agree that having both cases (sections) in the Makefile is a bad idea.
Still, why should we keep the in-tree build instructions?

Would it be possible instead to instruct PGXN to work with a non
installed server source tree? And how much do we need that really?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jun 16, 2013, at 9:20 AM, Cédric Villemain <cedric@2ndquadrant.com> wrote:

Then instead of the above you'd just be able to say something like

MODULETEST = test

or REGRESSDIR ?

Yeah, that sounds perfect.

Also I suggest to remove the need to set REGRESS at all, and default to all
sql files in REGRESSDIR/sql (if REGRESSDIR is set)

Yeah, that would be nice. If one has different file names or something, then one should still be able to set REGRESS.

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joe Conway wrote:

On 06/15/2013 11:28 AM, Alvaro Herrera wrote:

This use case seems too narrow to me to justify the burden of
keeping PGXS-enabled makefiles in contrib.

What was the burden of it?

Per /messages/by-id/1371093408.309.5.camel@vanquo.pezone.net :

: 1. take up space
: 2. confuse users
: 3. produce broken external extension modules that take contrib as an example
: 4. break builds of PostgreSQL when users try to fix 3. by exporting USE_PGXS

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le lundi 17 juin 2013 18:41:32, Alvaro Herrera a écrit :

Joe Conway wrote:

On 06/15/2013 11:28 AM, Alvaro Herrera wrote:

This use case seems too narrow to me to justify the burden of
keeping PGXS-enabled makefiles in contrib.

What was the burden of it?

Per http://www.postgresql.org/message-

id/1371093408.309.5.camel@vanquo.pezone.net :

: 1. take up space
: 2. confuse users
: 3. produce broken external extension modules that take contrib as an
: example 4. break builds of PostgreSQL when users try to fix 3. by
: exporting USE_PGXS

But:
4. can be fixed (see patches I sent) so it is not an excuse.

I agree for other points.
My only grief is to loose the perfect regression tests for PGXS those contribs
are.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

On Fri, 2013-06-14 at 09:32 -0400, Andrew Dunstan wrote:

I do think we need to make sure that we have at least buildfarm
coverage of pgxs module building and testing. I have some coverage of
a few extensions I have written, which exercise that, so maybe that
will suffice. If not, maybe we need to have one module that only
builds via pgxs and is build after an install (i.e. not via the
standard contrib build).

The way to test pgxs is to build actual pgxs modules, and possibly some
unit tests made for the purpose. Testing with fake hybrid modules that
will never actually appear that way in practice isn't going to satisfy
anyone.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, 2013-06-16 at 18:20 +0200, Cédric Villemain wrote:

Also I suggest to remove the need to set REGRESS at all, and default
to all sql files in REGRESSDIR/sql (if REGRESSDIR is set)

I'm not so sure about that. I have some extensions where the list of
tests is composed at build time depending on the target version (e.g.,
supports extensions, inline, event triggers, etc.). In a different
world, we'd have "skip" functionality for that sort of thing, but for
now building up the list of tests seems best.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, 2013-06-17 at 19:00 +0200, Cédric Villemain wrote:

My only grief is to loose the perfect regression tests for PGXS those
contribs are.

I think they are neither perfect nor regression tests. If we want
tests, let's write tests.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, 2013-06-17 at 11:41 +0200, Dimitri Fontaine wrote:

I agree that having both cases (sections) in the Makefile is a bad
idea.
Still, why should we keep the in-tree build instructions?

Would it be possible instead to instruct PGXN to work with a non
installed server source tree? And how much do we need that really?

We could do something like

PG_CONFIG = fake_intree_pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

where fake_intree_pg_config is a purpose-built shell script that points
to the right places inside the source tree.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le mercredi 19 juin 2013 04:58:15, Peter Eisentraut a écrit :

On Mon, 2013-06-17 at 19:00 +0200, Cédric Villemain wrote:

My only grief is to loose the perfect regression tests for PGXS those
contribs are.

I think they are neither perfect nor regression tests. If we want
tests, let's write tests.

You are right.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Le jeudi 13 juin 2013 05:16:48, Peter Eisentraut a écrit :

This has served no purpose except to

1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an
example 4. break builds of PostgreSQL when users try to fix 3. by
exporting USE_PGXS

There is adequate material in the documentation and elsewhere (PGXN) on
how to write extensions and their makefiles, so this is not needed.
---
pursuant to discussion here:
/messages/by-id/512CEAB8.9010400@gmx.net

* Submission review: patch apply on HEAD, no doc or test required.

* Usability review
** Does the patch actually implement that? yes
** Do we want that?

Consensus is not complete: some use case raised.

1/ regression test: not a good excuse, see [1]http://www.postgresql.org/message- id/1371610695.13762.25.camel@vanquo.pezone.net

2/ being able to build contrib out of tree, it is unsure it is really needed
on its own but was suggested. See [2]http://www.postgresql.org/message- id/1371172850.79798.YahooMailNeo@web193505.mail.sg3.yahoo.com and [3]/messages/by-id/51BBE3A5.40607@2ndquadrant.com

Arguments against removal are new features (extension layout, more work on
PGXS shoulders, extension headers exported, clean regression test for PGXS)

** Does it follow the community-agreed behavior?

Some people voiced against the idea. More answers might be better to confirm
that this is wanted. Amul, Joe, Craig ?

** Are there dangers?

The only I can see is packagers building contribs with PGXS, but as it is
currently buggy I'm sure they can't do that.

* Feature test: it deprecates a not-fully-implemented-feature (even fully
implemented this may not be considered a feature at all)

* Performance review: not relevant (contribs may build some µs faster...)

* Coding review: OK

* Architecture review: looks good too.

The patch needs to reach consensus before commit. There is no status for that
in CF, for me current status is: 'Ready, Waiting more feedback from
community'.

[1]: http://www.postgresql.org/message- id/1371610695.13762.25.camel@vanquo.pezone.net
id/1371610695.13762.25.camel@vanquo.pezone.net
[2]: http://www.postgresql.org/message- id/1371172850.79798.YahooMailNeo@web193505.mail.sg3.yahoo.com
id/1371172850.79798.YahooMailNeo@web193505.mail.sg3.yahoo.com
[3]: /messages/by-id/51BBE3A5.40607@2ndquadrant.com

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Peter Eisentraut <peter_e@gmx.net> writes:

We could do something like

PG_CONFIG = fake_intree_pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

There's something to that idea. Of course we would need to offer a
comment about the PG_CONFIG game and propose something else for real
world extensions (PG_CONFIG ?= pg_config).

where fake_intree_pg_config is a purpose-built shell script that points
to the right places inside the source tree.

If that works, that gets my preference over removing PGXS support in
contrib modules. Setting an example is important, in-tree build is not
a useful example for anyone but contributors to core.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

We could do something like

PG_CONFIG = fake_intree_pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

There's something to that idea. Of course we would need to offer a
comment about the PG_CONFIG game and propose something else for real
world extensions (PG_CONFIG ?= pg_config).

where fake_intree_pg_config is a purpose-built shell script that points
to the right places inside the source tree.

If that works, that gets my preference over removing PGXS support in
contrib modules. Setting an example is important, in-tree build is not
a useful example for anyone but contributors to core.

Not true - you're forgetting there is no pgxs for MSVC builds.

If we're going to enable building of contrib modules using pgxs but
without an install we will make targets for that, and buildfarm support.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:

Not true - you're forgetting there is no pgxs for MSVC builds.

Oh, indeed, totally forgot about that.

If we're going to enable building of contrib modules using pgxs but without
an install we will make targets for that, and buildfarm support.

So we would need some kind of windows only pgxs.pl script?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/19/2013 04:47 PM, Dimitri Fontaine wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Not true - you're forgetting there is no pgxs for MSVC builds.

Oh, indeed, totally forgot about that.

If we're going to enable building of contrib modules using pgxs but without
an install we will make targets for that, and buildfarm support.

So we would need some kind of windows only pgxs.pl script?

Well, MSVC support and buildfarm support are two separate issues.

For out of tree MSVC builds we would probably need to install a
substantial part of src/tools/msvc, and have a script that could
generate a Project and so on. I'm happy to help but it probably needs
someone with a deeper knowledge than I have of the internal workings of
MSVC project files to build it.

It's worth doing - I know some people who find this a major barrier.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le mercredi 19 juin 2013 22:22:22, Andrew Dunstan a écrit :

On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

We could do something like

PG_CONFIG = fake_intree_pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

There's something to that idea. Of course we would need to offer a
comment about the PG_CONFIG game and propose something else for real
world extensions (PG_CONFIG ?= pg_config).

where fake_intree_pg_config is a purpose-built shell script that points
to the right places inside the source tree.

If that works, that gets my preference over removing PGXS support in
contrib modules. Setting an example is important, in-tree build is not
a useful example for anyone but contributors to core.

Not true - you're forgetting there is no pgxs for MSVC builds.

PGXS + MSVC is still in the TODO list.... I won't be able to work on that.

If we're going to enable building of contrib modules using pgxs but
without an install we will make targets for that, and buildfarm support.

With the set of patches I sent, contrib can be built with PGXS, there is no
issue here....Except maybe pg_xlogdump, and this one might be improved not to
have to rebuild shared object from postgresql (IIRC it is a static build or
something like that)...

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Peter, Cedric, etc.:

Where are we on this patch? Seems like discussion died out. Should it
be bounced?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le mercredi 3 juillet 2013 23:56:42, Josh Berkus a écrit :

Peter, Cedric, etc.:

Where are we on this patch? Seems like discussion died out. Should it
be bounced?

I for myself have been presuaded that it is a good idea. Things apparently loosed are not, it just outline that we need better coverage in PGXS area, so it is another thing to consider (TODO : add resgress test for PGXS ...)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

On 07/04/2013 06:11 AM, Cédric Villemain wrote:

Le mercredi 3 juillet 2013 23:56:42, Josh Berkus a écrit :

Peter, Cedric, etc.:

Where are we on this patch? Seems like discussion died out. Should it
be bounced?

I for myself have been presuaded that it is a good idea. Things apparently loosed are not, it just outline that we need better coverage in PGXS area, so it is another thing to consider (TODO : add resgress test for PGXS ...)

To be more focused: is this patch going to be committed in the next 4
days or not? If not, it's time to mark it "returned" so we can have
leisurely spec argument later.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 07/10/2013 09:04 PM, Josh Berkus wrote:

On 07/04/2013 06:11 AM, Cédric Villemain wrote:

Le mercredi 3 juillet 2013 23:56:42, Josh Berkus a écrit :

Peter, Cedric, etc.:

Where are we on this patch? Seems like discussion died out. Should it
be bounced?

I for myself have been presuaded that it is a good idea. Things apparently loosed are not, it just outline that we need better coverage in PGXS area, so it is another thing to consider (TODO : add resgress test for PGXS ...)

To be more focused: is this patch going to be committed in the next 4
days or not? If not, it's time to mark it "returned" so we can have
leisurely spec argument later.

I think that would probably be the better course. I'm not sure there is
a consensus about this.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers