On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Peter Eisentraut wrote:
On 11/27/14 3:10 PM, Tom Lane wrote:
I'm not too happy with that approach, because packagers are going to
tend to think they should package any files installed by install-world.
The
Michael Paquier wrote:
It would be good to be consistent on Windows with what is now done on other
platforms: those modules should not be installed by default, but it would
be good to make install.pm a bit smarter with for example an option full,
aka install server + client + test modules.
Michael Paquier wrote:
On Wed, Dec 17, 2014 at 6:02 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Andrew Dunstan wrote:
Any brave buildfarm owners on *nix can try it by replacing their copy of
run_build.pl with the bleeding edge version. We can't put it in a client
release
Andrew Dunstan and...@dunslane.net writes:
On 12/16/2014 04:44 PM, Tom Lane wrote:
I've put this in dromedary as well (though the HEAD build that's running
right this moment is still using the 4.13 script). I take it I don't need
to adjust the configuration file?
Nope, no config changes
On 12/17/2014 10:23 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/16/2014 04:44 PM, Tom Lane wrote:
I've put this in dromedary as well (though the HEAD build that's running
right this moment is still using the 4.13 script). I take it I don't need
to adjust the
On 12/17/2014 11:34 AM, Andrew Dunstan wrote:
On 12/17/2014 10:23 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/16/2014 04:44 PM, Tom Lane wrote:
I've put this in dromedary as well (though the HEAD build that's
running
right this moment is still using the 4.13
Andrew Dunstan and...@dunslane.net writes:
On 12/17/2014 11:34 AM, Andrew Dunstan wrote:
Oh, darn, I thought we had a version check. Will fix.
OK, I have committed a fix. Revised script is at
On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I also attach some changes for the MSVC build stuff. I tested it and it
builds fine AFAICT, but it doesn't install because Install.pm wants to
install contrib modules from contrib/ (which seems reasonable) but my
Hi Andrew,
Did you have a chance to review this?
Alvaro Herrera wrote:
Andrew Dunstan wrote:
On 11/29/2014 10:09 PM, Alvaro Herrera wrote:
Anyway I just pushed this src/test/modules/ patch, which has
implications for buildfarm: these new test modules are not invoked
except
On 12/16/2014 09:31 AM, Alvaro Herrera wrote:
Hi Andrew,
Did you have a chance to review this?
Oh, darn, not yet. I will try to take a look today.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 12/16/2014 11:22 AM, Andrew Dunstan wrote:
On 12/16/2014 09:31 AM, Alvaro Herrera wrote:
Hi Andrew,
Did you have a chance to review this?
Oh, darn, not yet. I will try to take a look today.
I have pushed this change, and crake will be running the code. See
Andrew Dunstan wrote:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Crake just uploaded its first test results with the testmodules stuff
working:
On 12/16/2014 04:02 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Crake just uploaded its first test results with the testmodules
Andrew Dunstan and...@dunslane.net writes:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Any brave buildfarm owners on *nix can try it by replacing their copy of
run_build.pl
On 12/16/2014 04:44 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Any brave buildfarm owners on *nix can try it by
On Wed, Dec 17, 2014 at 6:02 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Andrew Dunstan wrote:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Crake just uploaded its
On 11/27/14 3:10 PM, Tom Lane wrote:
I'm not too happy with that approach, because packagers are going to
tend to think they should package any files installed by install-world.
The entire point of this change, IMO, is that the test modules should
*not* get installed, certainly not by normal
On 2014-11-27 15:51:51 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So test_decoding is fairly useful for users demonstrating that decoding
works, especially if they're also testing an external decoding module
and are unsure of where their replication problem is located, or
On 11/27/2014 12:51 PM, Tom Lane wrote:
So test_decoding is fairly useful for users demonstrating that decoding
works, especially if they're also testing an external decoding module
and are unsure of where their replication problem is located, or what's
wrong with their HBA settings. For
Peter Eisentraut wrote:
On 11/27/14 3:10 PM, Tom Lane wrote:
I'm not too happy with that approach, because packagers are going to
tend to think they should package any files installed by install-world.
The entire point of this change, IMO, is that the test modules should
*not* get
Peter Eisentraut wrote:
On 11/26/14 9:27 AM, Alvaro Herrera wrote:
I haven't done anything about documentation. I thought a new chapter
after Additional Supplied Modules, perhaps entitled Additional Sample
Modules would be appropriate.
I would remove the SGML files and put simple README
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I have also changed things so that:
1. test modules are not installed by make install, not checked by
make installcheck, not checked by make check.
2. test modules are checked by make check-world (this is consistent
with handling of contrib).
On 11/24/2014 05:49 AM, Alvaro Herrera wrote:
test_parser (a toy text search parser, added in 2007)
dummy_seclabel (for SECURITY LABEL regression testing, added Sept 2010)
worker_spi (for bgworkers, added Dec 2012)
test_shm_mq (test program for shared memory queues, added Jan 2014)
Josh Berkus j...@agliodbs.com writes:
So test_decoding is fairly useful for users demonstrating that decoding
works, especially if they're also testing an external decoding module
and are unsure of where their replication problem is located, or what's
wrong with their HBA settings. For that
Tom Lane wrote:
I'm not too happy with that approach, because packagers are going to
tend to think they should package any files installed by install-world.
The entire point of this change, IMO, is that the test modules should
*not* get installed, certainly not by normal install targets.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh Berkus
Sent: Friday, November 28, 2014 5:48 AM
To: Alvaro Herrera; Pg Hackers
Subject: Re: [HACKERS] no test programs in contrib
On 11/24/2014 05:49 AM, Alvaro
Here's a patch. This creates a new subdir src/test/modules and places
the five initially proposed modules in there. They continue to have
their makefile with the same ifdef USE_PGXS pattern; they are no longer
installed by default.
Because many of them had either test in their names or some
On Wed, Nov 26, 2014 at 9:27 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a patch. This creates a new subdir src/test/modules and places
the five initially proposed modules in there. They continue to have
their makefile with the same ifdef USE_PGXS pattern; they are no longer
On Wed, Nov 26, 2014 at 12:27 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a patch. This creates a new subdir src/test/modules and places
the five initially proposed modules in there. They continue to have
their makefile with the same ifdef USE_PGXS pattern; they are no longer
This is pretty bulky, but really the vast majority of the changes here
are just git mv.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
test_modules.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing
On 2014-11-26 10:08:57 -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
This is pretty bulky, but really the vast majority of the changes here
are just git mv.
For ease of review, is there a way to get git to show just the diffs that
*aren't* git mv? (That is, show
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
This is pretty bulky, but really the vast majority of the changes here
are just git mv.
For ease of review, is there a way to get git to show just the diffs that
*aren't* git mv? (That is, show changes in a file's content
Robert Haas wrote:
On Wed, Nov 26, 2014 at 9:27 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Because many of them had either test in their names or some other
now-useless particle, I renamed them:
worker_spi - bgworker
test_decoding - logical_decoding
On 11/26/14 9:27 AM, Alvaro Herrera wrote:
I haven't done anything about documentation. I thought a new chapter
after Additional Supplied Modules, perhaps entitled Additional Sample
Modules would be appropriate.
I would remove the SGML files and put simple README files into each
directory.
On 11/24/14 8:49 AM, Alvaro Herrera wrote:
What would you say if we were to move them to src/test/?
Yes please.
Now, I know there is some resistance to the idea of moving source code
around.
I think clarifying contrib is more important than that.
--
Sent via pgsql-hackers mailing list
On 11/24/14 9:35 AM, Andres Freund wrote:
I actually think that test_decoding is somewhat useful in other cases as
well, so it might be prudent to leave it there.
For what?
src/test/ is good, but I think there should be another subdirectory
inside. testcases/?
What tests are not test cases?
On 11/24/14 10:46 AM, Tom Lane wrote:
I think that test_parser is arguably useful as a skeleton/example for
user-written TS parsers, so I'd lean towards leaving it where it is,
but the others could move to src/test/ IMO.
I think a useful dividing line would be, is it normally useful to
On 2014-11-25 16:07:52 -0500, Peter Eisentraut wrote:
On 11/24/14 9:35 AM, Andres Freund wrote:
I actually think that test_decoding is somewhat useful in other cases as
well, so it might be prudent to leave it there.
For what?
src/test/ is good, but I think there should be another
Peter Eisentraut pete...@gmx.net writes:
On 11/24/14 10:46 AM, Tom Lane wrote:
I think that test_parser is arguably useful as a skeleton/example for
user-written TS parsers, so I'd lean towards leaving it where it is,
but the others could move to src/test/ IMO.
I think a useful dividing line
On 24/11/14 14:49, Alvaro Herrera wrote:
I'm now contemplating the addition on a new one in the commit-timestamps
patch, and I'm starting to feel that these are all misplaced. I think
we have been dumping them to contrib not because they really belong
there, but because of the lack of a better
Hi,
On 2014-11-24 10:49:45 -0300, Alvaro Herrera wrote:
I'm now contemplating the addition on a new one in the commit-timestamps
patch, and I'm starting to feel that these are all misplaced. I think
we have been dumping them to contrib not because they really belong
there, but because of the
Alvaro Herrera alvhe...@2ndquadrant.com writes:
We currently have a number of subdirectories for test-only programs:
test_parser (a toy text search parser, added in 2007)
dummy_seclabel (for SECURITY LABEL regression testing, added Sept 2010)
worker_spi (for bgworkers, added Dec 2012)
On Mon, Nov 24, 2014 at 10:49:45AM -0300, Alvaro Herrera wrote:
What's the general opinion on having test programs somewhere other than
contrib/ ?
General opinion: slightly favorable.
We currently have a number of subdirectories for test-only programs:
test_parser (a toy text search
43 matches
Mail list logo
