The proposal on the table is to bundle plPHP into the Postgres source
package, and the problem is that that introduces a circular dependency
at build time because PHP already made a similar bundling. That was a
bad move on their part and we shouldn't compound the problem by making
a similar error.
I understand your point Tom. However as I said in a earlier
post, just because it is in core doesn't mean they have to
package it.
The users themselves will either generate the demand for the
package or not, and the packagers can then choose based on
that demand.
Frankly I don't think we should care if PHP is borked on
their API or build process. We should care if plPHP is:
A. Quality enough software (and yes it needs some work) to
go into core.
B. Appropriate for the PostgreSQL user base.
Obviously my opinion is that B is met and A is being worked
on.
Sincerely,
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@xxxxxxxxxxxxxxxxx - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:jd@xxxxxxxxxxxxxxxxx
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
