Re: Int64GetDatum

Поиск
Список
Период
Сортировка
От John R Pierce
Тема Re: Int64GetDatum
Дата
Msg-id 4BC89503.5010807@hogranch.com
обсуждение исходный текст
Ответ на Re: Int64GetDatum  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: Int64GetDatum  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Int64GetDatum  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Tuple storage overhead
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Int64GetDatum