Re: plPHP and plRuby - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: plPHP and plRuby
Date
Msg-id 44BE8025.5080500@cheapcomplexdevices.com
Whole thread Raw
In response to Re: plPHP and plRuby  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: plPHP and plRuby  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut wrote:
> Hannu Krosing wrote:
>> So we would have
>> src/pl/pljava/README.TXT
>>
>> and anybody looking for pl-s would find the info in a logical place
> 
> Right.  When was the last time any user looked under src/pl in the first 
> place?  Or even under src?  If you're looking for pljava, it's the 
> first hit in Google.

The difference is that I will have reasonable confidence that
the README.TXT under "src/pl" will give instructions that match
the version of PostgreSQL that I have.   I assume that README
will call out the version of PL/R or PL/Ruby that I want that
was tested with the release of PostgreSQL I have.

The first hit on Google will probably give me the most
recently blogged about version; which does nothing to help
me find what I need.

> The organization of the source code is controlled by exactly two 
> factors:
> 2. convenience of development

I thought "convenience of development" included the addressing
the problem that PLs are annoyingly deeply tied to specific
versions of Core.

I would imagine with this README.TXT proposal, it's the responsibility
of the PL/XXX developer to port their PL to PostgreSQL during the Beta,
and if the did and tested it, the release will point to the version
of the PL supported by the PL maintainer for that version.   If they
don't do this testing during the beta, the README.TXT may merely say
the "PL/Haskell team did not complete testing during the 8.2 beta; so
good luck".

This aids to the convenience of development of PostgreSQL and the PLs
because it defines the process and responsibility for integration
testing the PLs with the Core releases; and puts some pressure to
synchronize the releases.

> Anything else is between you and your packager.
> 
> And if that didn't convince you, I still got PL/sh in the wait ...

With which versions of PostgreSQL is this version of PL/sh supported?
I see that PL/sh on http://pgfoundry.org/projects/plsh/ is version 1.1?
Does that mean it goes with PostgreSQL 1.1?   The Projects page
for PL/SH (http://plsh.projects.postgresql.org/) suggests it was
last modified in May 2005 - does that mean I need the May 2005 backend
of PostgreSQL to compile it?  Oh.  The download page says older
releases are also supported.  Does that include 7.1?

Putting this info in the README.TXT is one way to help users
know what's supported.   If I saw a README.TXT for pl/sh I'd
have some confidence I'd be directly pointed to the version I need.


pgsql-hackers by date:

Previous
From: "Bort, Paul"
Date:
Subject: Re: pg_regress breaks on msys
Next
From: Tom Lane
Date:
Subject: Re: pg_regress breaks on msys