Re: [PATCHES] plperl and pltcl installcheck targets - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCHES] plperl and pltcl installcheck targets
Date
Msg-id 42823DF2.2070108@dunslane.net
Whole thread Raw
Responses Re: [PATCHES] plperl and pltcl installcheck targets  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
[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


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: 7.3.10 working
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Views, views, views: Summary of Arguments