On Mon, 17 May 2004, Jan Wieck wrote:
> They are not as independant as one might think. The core support for set
> returning functions is required before a PL can do it. Same was with
> cursors and same will be with subtransactions being the base for
> exception handling. People have been struggling with unloadable shared
> objects from another version due to elog changes, I can't imagine what
> kind of support horror we're creating with this now.
k, how is this different then any other software package that has to be
extended to make use of new features? For instance, when subtransactions
get added, is that same person going to extended the various pls as well?
Or, more likely, when subtransactions are added, will someone responsible
for each of the pls submit patches to extend them?
Having pl/pgsql included as a 'reference implementation' is reasonable ...
I just think that pl/<pick your language here> should be on pgfoundry ...
> If we completely lose the ability to tell what version of what PL,
> client interface or extension works with what version of the backend,
> we're losing some important detail here.
Why is it our responsibility to ensure that though? Shouldn't the
developer (or group of developers) responsible for the
PL/interface/extension be responsible for that?
Let's use plPHP as an example here ... I'm going to guess that it supports
PHP4, which is the 'standard' right now ... what about PHP5? If not, what
happens in 3 months if/when that support is added? Do ppl using PHP5 have
to wait until the next release of PostgreSQL before they can use it?
If, instead, plPHP is on pgfoundry, there is nothing that stops them
adopting a release numbering in parallel to the core distribution, at
least in so far as major.minor ... but they could release a
major.minor.minor release as required seperate from our release cycle that
still matches our latest stable, but extends itself to working with PHP5,
as an example ...
The thing is, whether as part of core, or as a seperate project, *any*
pl/interface/extension has to be maintained in order to be in sync ... if
done as a seperate project, in parallel with core, it is at least
possible to release on their own timelines in order to correct bugs, or
add features ... as part of core, new features/bug fixes have to wait for
all of core to be released ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
