Re: Int64GetDatum

From: John R Pierce <pierce(at)hogranch(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Int64GetDatum
Date: 2010-04-16 16:49:07
Message-ID: 4BC89503.5010807@hogranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-04-16 16:55:57 Re: Int64GetDatum
Previous Message Merlin Moncure 2010-04-16 15:28:36 Re: Tuple storage overhead