Re: [PATCHES] libpq type system 0.9a
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] libpq type system 0.9a |
Дата | |
Msg-id | 47FCCB9E.1070008@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] libpq type system 0.9a (Andrew Chernow <ac@esilo.com>) |
Ответы |
Re: [PATCHES] libpq type system 0.9a
|
Список | 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. They would get it the same way they would get anything else that uses libpq that isn't packaged with it (e.g. DBD::Pg). They would either get the package that contains it, if it exists, or get the source and build it. The package with the dependent library might belong in the extras collection, while Tom's goal (and it's a good one) is to keep libpq in the core collection. I don't get what you're not seeing about this. cheers andrew
В списке pgsql-hackers по дате отправления: