Actually this is a pretty good example. Yes right now it supports PHP4, it will support PHP5 when PHP5 is ready.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?
And of course, no they would not have to wait. They could download and patch against the current
source tree...
Well actually no, because of the above mentioned. Even if plPHP is on pgFoundry... there is noThe 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 ...
reason why a README couldn't be included in the src/pl/plphp directory that says: look here
for the latest release etc...
Sincerely,
Joshua D. Drake
---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
