Re: Future of src/utils - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Future of src/utils
Date
Msg-id 9131.1026858453@sss.pgh.pa.us
Whole thread Raw
In response to Re: Future of src/utils  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Future of src/utils  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Future of src/utils  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't think we need to move the subdirectories, which involve stuff
> that's heavily tied to the backend.  But the generic C library replacement
> files should move into src/utils preferably.  In fact, what we could do is
> assemble all the files we need (as determined by configure) into a static
> library and link all executables with that.  That way we don't have to
> deal with the individual files in each individual makefile.

I like that a lot.  But will it work for libpq?  I have a feeling we'd
end up linking *all* the replacement functions into libpq, which might
create some namespace issues for client applications.  Ideally we should
only link the functions libpq actually needs into libpq, but I'm not
sure that works with standard linker behavior.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: bit type external representation
Next
From: Tom Lane
Date:
Subject: Do we still need these NOTICEs?