Magnus Hagander wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names). The latter is no longer a problem on
>> platforms that support exported-name filtering, but that isn't all of
>> them. Could we consider splitting path.c into two parts, that which we
>> want in libpq and that which we don't?
>
> On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that
> size *really* a problem?
>
> Also, is there a chance that the linker is smart enough to actually
> remove the parts of path.o that aren't used in libpq completely, if it's
> not exported at all? (if the size does matter)
>
> If it is, sure, we could split it apart. But fairly large parts of it
> would be required by both. But I guess the number of symbols would be
> quite a bit smaller.
Answering myself here: the filesize for the "frontend only" part is
about 2k on this system.
//Magnus
