Re: Int64GetDatum

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

John R Pierce <pierce(at)hogranch(dot)com> writes:
> 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?

No, but trying to build against a non-self-consistent set of files is
bad. You really need a pg_config.h that matches the original build of
the server, and you haven't got that. I think Greg's point is that
trying to reverse-engineer that file is considerably more risky than
building your own packages from scratch.

> 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.

Right. If you can get a consistent fileset from Bjorn in a timely
fashion, problem solved.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Maurício Ramos 2010-04-16 17:19:41 Specif postgres version
Previous Message John R Pierce 2010-04-16 16:49:07 Re: Int64GetDatum