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.
> 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.)
> 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.
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?
regards, tom lane