Re: Int64GetDatum

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Int64GetDatum
Дата
Msg-id 11309.1271436957@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Int64GetDatum  (John R Pierce <pierce@hogranch.com>)
Ответы Re: Int64GetDatum  (John R Pierce <pierce@hogranch.com>)
Re: Int64GetDatum  (John R Pierce <pierce@hogranch.com>)
Список pgsql-general
John R Pierce <pierce@hogranch.com> writes:
> 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?

No, but trying to build against a non-self-consistent set of files is
bad.  You really need a pg_config.h that matches the original build of
the server, and you haven't got that.  I think Greg's point is that
trying to reverse-engineer that file is considerably more risky than
building your own packages from scratch.

> 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.

Right.  If you can get a consistent fileset from Bjorn in a timely
fashion, problem solved.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: John R Pierce
Дата:
Сообщение: Re: Int64GetDatum
Следующее
От: Maurício Ramos
Дата:
Сообщение: Specif postgres version