Re: Int64GetDatum
От | John R Pierce |
---|---|
Тема | Re: Int64GetDatum |
Дата | |
Msg-id | 4BC89503.5010807@hogranch.com обсуждение исходный текст |
Ответ на | Re: Int64GetDatum (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Int64GetDatum
Re: Int64GetDatum |
Список | pgsql-general |
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? then whats the point of the whole pgxs system and including server headers in a binary release? compiling a plugin like pl/java makes no reference to the source tree at all, rather, it uses the lib/pgxs/src/Makefile.global and include/server/*.h which are part of a binary release. 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. fyi, the packages in question are the 8.4.x ones here, http://www.postgresql.org/download/solaris as well as the ones provided by Sun (which I believe come from the same packager)
В списке pgsql-general по дате отправления: