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
