Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.
More than a little ugly, no thanks, please don't...
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Sincerely,
Joshua D. Drake
Command Prompt, Inc.
It should really be made to be buildable outside of the PostgreSQL
source tree, depending only upon the server API (which is provided in a
seperate Debian package which plphp could build-depend on). This is
exactly how Slony will be packaged too.. From what I've gathered it
sounds like the only issue with this is that it may not get updated when
the server API changes? Are there other issues? Is there something it
needs that isn't or can't be provided by a seperate server API package?
(For those curious- my current plans are that slony will actually
generate a couple differnet binary debs, slon, slonik and
libpostgresql-slon or so. libpostgresql-slon will have the .so which is
installed in the postgresql libdir, slon and slonik have their
associated programs and supporting things (.sql scripts, etc)).
Thanks,
Stephen
---------------------------(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
