Re: [PATCHES] libpq type system 0.9a

Поиск
Список
Период
Сортировка
От Andrew Chernow
Тема Re: [PATCHES] libpq type system 0.9a
Дата
Msg-id 47FCC54C.5010605@esilo.com
обсуждение исходный текст
Ответ на Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
Список pgsql-hackers
Andrew Chernow wrote:
> Andrew Chernow wrote:
>>>
>>> Well, I can get it working with a very small patch.  We actually 
>>> don't need very much in libpq.  Although, making it somehow generic 
>>> enough to be useful to other extensions is a bit tricky.  Please, 
>>> suggestions would be helpful.
>>>
>>
> 
> Quick question on the hook concept before I try to supply a new patch.
> 
>  From my experience, redhat normally compiles everything into their 
> packages; like apache modules.  Why would libpq be any different in 
> regards to libpqtypes?
> 
> If they don't distribute libpqtypes, how does a libpq user link with 
> libpqtypes?  They don't have the library.  Where would they get a 
> libpqtypes.so that is compatible with redhat's supplied libpq.so?
> 
> The core of what I am trying to ask is, there doesn't appear to be an 
> advantage to separating libpqtypes from libpq in terms of space.  If 
> redhat follows their normal policy of include all (probably to make 
> their distro as feature rich out-of-the-box as possible), then they 
> would distribute libpqtypes.so which would use the same amount of space 
> as if it were part of libpq.
> 


By the way, I offered up the idea of compiling our patch in or out, 
./configure --with-pqtypes.  But Tom had said
>>[shrug...] So the packagers will compile it out, and you're>>still hosed, or at least any users who'd like to use it
are.

If redhat would compile out our patch, no questions asked, why would 
they distribute libpqtypes.so.  Meaning, separating it out doesn't seem 
to unhose us :)

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/


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

Предыдущее
От: Andrew Chernow
Дата:
Сообщение: Re: [PATCHES] libpq type system 0.9a
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: SQL fast in PSQL, very slow using MS.NET driver