Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane 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?
I'm more worried about the external dependencies pulled in by the
path-discovery stuff (geteuid for instance). None of that is code
that libpq needs at all.
> 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)
The normal expectation is that .o files are the unit of linking. There
might be a platform or two that is smarter, but they are not the norm.
Since I'm the one who's hot about this, I'm willing to do the work.
Do you agree that canonicalize_path and make_native_path are all that
we want to push into libpq for now? If so, I'll rename them to
pg_..._path and push them into a separate source file.
regards, tom lane
