Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane: > Hannu Krosing <[EMAIL PROTECTED]> writes: > >> Sven Suursoho wrote: > >>> As for testing in actual pl/python build environment, we had objections > >>> from > >>> leading postgresql Tom Lane that even if we do test it at build time, > >>> a determined DBA may substitute a buggy python.so later and still crash > >>> her DB instance. > > The above is a straw-man depiction of my point.
Sure ;) > What I said was that just > because python is up-to-date on the system where plpython is *compiled* > does not mean it'll be up-to-date on the system where plpython is *used*. Would running an external program at pl init time and testing for its crash status be a good broken lib test for plpython ? > With the increasing popularity of prebuilt packages (rpm, deb, etc), > I think it's folly to use a build-time check for this. I guess most packaging systems can require some minimal version of dependencies. And in general newer versions are less buggy than old ones. So i guess that some combination of build-time/run-time tests, documentation and packager education should take care of 99% of concerns ? Hopefully we can just ignore the "determined DBA" failure mode and move forward with including the patch. Or do you think that trying to hack in the extra python frame to all/some builds to ward of potentially broken libs would still be something to go for ? -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com NOTICE: This communication contains privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster