Re: Path separator - Mailing list pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> In view of the way that canonicalize_path() works, I can't help thinking
>>> this is going in precisely the wrong direction.
> 
>> In a way, yes. But canonicalize_path() runs only in the backend, and
>> this is only in the frontend. I think the requirements on the frontend
>> are slightly different than the backend.
> 
> Just for the record, canonicalize_path does work in the frontend;
> we have uses of it in psql and pg_ctl.  But we have previously decided
> not to import path.c into libpq, which is where the present issue is,
> so yes there is a problem with using it.  The same objection applies to
> make_native_path unfortunately.

That's what I meant. And yeah, that's true about make_native_path as well.

Should we reconsider this decision?


>> But the most important thing is to be consistent within the same path as
>> we report it I think, so we could switch all to forward slashes as well
>> if you think that's better.
> 
> What I'm concerned about is the prospect that if we do this here,
> we're going to end up trying to do it all over the frontend code.
> (And I'm not entirely convinced that it doesn't then propagate into
> the backend, too, but even just the frontend code is bad enough.)

True.


>> I just realized we have a make_native_path() function, I had completely
>> missed that one. So we could possibly use that instead. In the end it
>> does the same thing
> 
> I'd definitely favor using make_native_path over hand-rolled code.
> But I guess what I'm suggesting is that it'd be more consistent with
> our previous choices to apply canonicalize_path instead.

I agree that this is probably the best way to do it.


> 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.

Is it worth taking a look at exactly what the sizes end up being?
Shouldn't be all that much work...

//Magnus