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