Re: Int64GetDatum - Mailing list pgsql-general

From John R Pierce
Subject Re: Int64GetDatum
Date
Msg-id 4BC89503.5010807@hogranch.com
Whole thread Raw
In response to Re: Int64GetDatum  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Int64GetDatum  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Int64GetDatum  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-general
Greg Smith wrote:
> If I were John, I'd be preparing to dig in on providing a complete
> source build with PL/Java installed.  It looks like the idea that
> they'll be able to take their *existing* Solaris binaries and just add
> Java on top of them is going to end up more risky than doing that.
> The best approach for this situation as far as I'm concerned is a
> build to a completely alternate location, not even touching the system
> PostgreSQL.  Then you can slide the new version onto there without
> touching the known working one at all, just swap the paths around--and
> rollback is just as easy.

so you're saying that building plugins to work with an existing system
is bad?   then whats the point of the whole pgxs system and including
server headers in a binary release?

compiling a plugin like pl/java makes no reference to the source tree at
all, rather, it uses the lib/pgxs/src/Makefile.global and
include/server/*.h which are part of a binary release.

I'm simply dealing with a situation here where the packager of the
Solaris binary didn't realize those files varied between 32 and 64, and
neglected to include the right ones in the 64bit build.  He's popped up
on hackers, and is looking into it now.

fyi, the packages in question are the 8.4.x ones here,
http://www.postgresql.org/download/solaris   as well as the ones
provided by Sun (which I believe come from the same packager)



pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Tuple storage overhead
Next
From: Tom Lane
Date:
Subject: Re: Int64GetDatum