John R Pierce wrote:
so you're saying that building plugins to work with an existing system is bad? then whats the point of the whole pgxs system and including server headers in a binary release?
It's fine if your package has been setup to allow it. I bundle up stuff on RHEL like that all the time, works fine. What I'm suggesting is that as soon as that assumption is proven to be false, which is the case for you, the most straightforward way to make sure you have a consistent database+extension set is to build the whole stack together yourself.
If you can get this resolved via Bjorn fast enough for you, that may turn out to be fine. But recognize that even in that case, you may end up swapping around files related to the basic server portion of your production system to pull those fixes in--exactly the thing you are suggesting is off limits. Once you've demonstrated that the files on the server already really aren't suitable for the job you need them for, this idea that they're the sacred set that must not be touched is busted anyway. At that point, I start thinking in terms of how I'm going to test this out and how rollback in case of a problem is going to work, and that can turn to be harder to handle with a change to the system database installation than via running your own set of binaries in parallel with it.
I'm not trying to criticize what you're doing, just given you a dose of my own paranoia and preferred risk management approach for this sort of thing. It may not actually be possible to fully follow the unreasonable requirements you've been given and deliver something that works well.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
