John R Pierce <pie...@hogranch.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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
