Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Also, some commentary connecting this test to plperl.c's support for
two interpreters would be a good thing.
ITYM in the .sql file(s)?
No, the test in the makefile is what seems to need a comment. It
doesn't
Andrew Dunstan writes:
> Tom Lane wrote:
>> Also, some commentary connecting this test to plperl.c's support for
>> two interpreters would be a good thing.
> ITYM in the .sql file(s)?
No, the test in the makefile is what seems to need a comment. It
doesn't have to be much. I was thinking somet
Tom Lane wrote:
Hm ... I wonder how badly this fails if perl isn't present?
Before you say that that won't matter, consider "make clean" etc.
The makefile does have to parse.
It might be sufficient to wrap this test in an "ifneq ($(PERL),)"
or similar.
OK, can do that.
Also, some comme
Andrew Dunstan writes:
> OK, here is a patch that provides for running regression tests for
> plperlu alone and plperl/plperlu interaction, skipping the latter if
> it's not supported on the platform, using the test Tim has suggested.
> ! ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplici
Tim Bunce wrote:
Or perhaps put the tests that require multiplicity into a plperl_multi.sql
file and add logic to the GNUmakefile to add that file to REGRESS
if "perl -V:usemultiplicity" returns "usemultiplicity='define';"
OK, here is a patch that provides for running regression tests f
On Wed, Jan 06, 2010 at 07:07:12PM -0500, Andrew Dunstan wrote:
>
> Alvaro Herrera wrote:
> >decibel wrote:
> >
> >>We've actually run into similar issues. Alvaro came up with a patch
> >>that fixes our specific issue, but I think he said there were some
> >>other cases that needed to be fixed as
Alvaro Herrera wrote:
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone looking to fix
this should ping Alvaro first.
No, what I fi
decibel wrote:
> We've actually run into similar issues. Alvaro came up with a patch
> that fixes our specific issue, but I think he said there were some
> other cases that needed to be fixed as well. Anyone looking to fix
> this should ping Alvaro first.
No, what I fixed was the contrib/xml2 cra
On Jan 6, 2010, at 5:46 PM, Andrew Dunstan wrote:
> Tim Bunce wrote:
>> I was investigating a bug in an 8.4.1 production system and distilled a
>> test case down to this:
>>
>>CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
>>#die 'BANG!'; # causes server process to exit(2)
>>
Tim Bunce wrote:
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("inv
11 matches
Mail list logo
