Tom Lane wrote:
> John R Pierce <pierce@hogranch.com> writes:
>
>> I need to build pl/java to run against the binary release of Postgres
>> for largely political/corporate reasons. this is to be installable as
>> an addon to an existing large/complex database deployment.
>>
>
> Well, in that case you'd better pester whoever packages the binary
> release you're using to ship a consistent set of files. What you
> have is a broken package, IMNSHO.
>
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.
I think the road these bad corporate mandates is leading toward is one
where you risk breaking the system database install by hacking it up
without a good rollback position in case of an unexpected problem.
That's something they'd get for free if they just accepted that the
whole database binary set needs to be replaced. Would have been
different if the Java just compiled and worked, but there's obviously
some deeper issues here. As Tom points out, the only solution there
might end up being a new binary set from the packager, which means a
wholesale swap of binaries anyway.
People should not make decisions about large/complex database
environments for political/corporate reasons when those reasons end up
increasing the risk of problems. If you get pushed around that way
regardless, a "I told you so" CYA memo suggesting as much would be
appropriate here, so you don't get blamed for any fallout.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us