John R Pierce <pierce@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general