> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
> Peter Eisentraut
>
> Taking a step back here, I see two points in favor of
> including PL/Java or
> something like it into the main CVS:
>
> 1. Build farm support
>
> It seems that eventually one would like to have build farm
> support for many
> things. I can see build farm support being useful for the
> ODBC driver or
> Postgis, for instance. We need a better, more general
> solution for that.
Does PL/Java really have to be in core to be tested in the build farm?
Could the build farm code be enhanced to test non-core stuff? (I like
the idea of a separate status 'light' for non-core.)
>
> 2. Help with PL API changes
>
> On the one hand, that seems great, but on the other hand, I
> see a lot of
> people disqualifying themselves from touching PL/Java code in
> any significant
> way because they don't know Java well enough. So I don't see
> this working in
> practice. Or at least, it's quite doubtful that the
> convenience gained in
> this area will outweigh any inconveniences coming from this move.
>
I think that if the buildfarm could alert us that there's a problem with
a PL when it happens, rather than discovering it way later, having the
code in the core repository is less critical.
Regarding the packagers who don't include non-core components that their
users might like, would a README.distros help? It could suggest good
things to include, where to find them, and tips for building. This could
also distinguish the mature packages on pgFoundry from the ones that are
not quite ready for prime time: when a package's maintainer(s) think
it's ready for production, they could submit a patch to the
README.distros that adds the package. (I'm not attached to the filename,
it just seemed less confusing than README.packagers.)
Regards,
Paul
