Thread: Re: [PATCHES] plperl and pltcl installcheck targets

[redirected to -hackers]

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Is it worth rearranging things for plpython so that it follows the same 
>>test layout as the other 2 (i.e. a test subdir with all the test files 
>>and a script called runtest that does the work)? Especially if we bring 
>>in other PLs as has been discussed, some standard might be useful.
>>    
>>
>
>Actually, we have a standard: it's pg_regress.  The right thing for
>someone to do is migrate all these tests into the form already used
>for the main backend and all of contrib.
>
>I think this would require a small addition to the pg_regress script
>to make it configurable as to which PL to install, instead of always
>installing plpgsql, but that seems like a reasonable thing to do.
>
>    
>  
>

I'm not sure why it would matter having it there. I would just make the 
first test to load the language in question - pretty much this, right?

CREATE FUNCTION "plperl_call_handler" () RETURNS language_handler AS 
'$libdir/plperl' LANGUAGE C;
CREATE TRUSTED LANGUAGE "plperl" HANDLER "plperl_call_handler";
CREATE LANGUAGE "plperlu" HANDLER "plperl_call_handler";

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I think this would require a small addition to the pg_regress script
>> to make it configurable as to which PL to install, instead of always
>> installing plpgsql, but that seems like a reasonable thing to do.

> I'm not sure why it would matter having it there. I would just make the 
> first test to load the language in question - pretty much this, right?

> CREATE FUNCTION "plperl_call_handler" () RETURNS language_handler AS 
> '$libdir/plperl' LANGUAGE C;
> CREATE TRUSTED LANGUAGE "plperl" HANDLER "plperl_call_handler";
> CREATE LANGUAGE "plperlu" HANDLER "plperl_call_handler";

The point is that I'd rather test createlang than duplicate it.

(In the back of my mind also is that running createlang is a waste of
time for the contrib tests, and so it'd be nice if pg_regress didn't
load any PL unless told to.)
        regards, tom lane

Tom Lane wrote:

>
>
>The point is that I'd rather test createlang than duplicate it.
>
>(In the back of my mind also is that running createlang is a waste of
>time for the contrib tests, and so it'd be nice if pg_regress didn't
>load any PL unless told to.)
>
>
>  
>

Aha. ok. should be fairly trivial. I'm thinking of something like
  --load-languages=lang1,lang2,lang3

(in case we ever want more than one).

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Aha. ok. should be fairly trivial. I'm thinking of something like
>    --load-languages=lang1,lang2,lang3
> (in case we ever want more than one).

Might be a little easier as multiple switches:--load-language=lang1 --load-language=lang2
        regards, tom lane