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
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 appa
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 bett
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.postgresq
Le mercredi 19 juin 2013 22:22:22, Andrew Dunstan a écrit :
> On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:
> > Peter Eisentraut writes:
> >> We could do something like
> >>
> >> PG_CONFIG = fake_intree_pg_config
> >> PGXS := $(shell $(PG_CONFIG) --pgxs)
> >> include $(PGXS)
> >
> > There's so
On 06/19/2013 04:47 PM, Dimitri Fontaine wrote:
Andrew Dunstan 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,
Andrew Dunstan 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 k
On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:
Peter Eisentraut 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 p
Peter Eisentraut 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 extens
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
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
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? A
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-hacker
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 depen
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 n
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
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.ca...@vanquo.pezone.net :
On Jun 16, 2013, at 9:20 AM, Cédric Villemain 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 R
Hi,
Peter Eisentraut 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 instr
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 wrote:
> >>REGRESS_OPTS = --inputdir=test --outputdir=test \
> >>
> >> --load-extension=$(EXTENSION)
> >>
> >>...
>
On 06/15/2013 02:43 PM, David E. Wheeler wrote:
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan wrote:
REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.ou
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan 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 testin
-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
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
> >> 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
> >> ME
On 06/15/2013 06:24 AM, Cédric Villemain wrote:
Andrew Dunstan 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 suc
Andrew Dunstan 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 contri
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
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 a
On Fri, Jun 14, 2013 at 9:35 PM, 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
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
- Original Message -
> From: Peter Eisentraut
> 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 s
On Jun 12, 2013, at 8:16 PM, 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
>
> T
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
34 matches
Mail list logo
