Re: Call for 7.5 feature completion - Mailing list pgsql-hackers
From | Marc G. Fournier |
---|---|
Subject | Re: Call for 7.5 feature completion |
Date | |
Msg-id | 20040517222150.H52585@ganymede.hub.org Whole thread Raw |
In response to | Re: Call for 7.5 feature completion (Jan Wieck <JanWieck@Yahoo.com>) |
Responses |
Re: Call for 7.5 feature completion
("Joshua D. Drake" <jd@commandprompt.com>)
|
List | pgsql-hackers |
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
pgsql-hackers by date: