>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@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
