Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../ - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../
Date
Msg-id 9781.1341384106@sss.pgh.pa.us
Whole thread Raw
In response to BUG #6715: 9.2b2 psql \ir does not understand leading ../  (jgd@well.com)
Responses Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../  (Josh Kupershmidt <schmiddy@gmail.com>)
List pgsql-bugs
jgd@well.com writes:
> When I do
> \ir ../bar.sql
> I get the bar.sql file in the CWD.

AFAICS, it works fine when \ir is used interactively.  However,
you seem to be using it from a script:

> $ psql -aX greg -f foo.sql

and then indeed it does not work so well.  psql is trying to evaluate
the \ir relative to the script file's location, using this code:

            snprintf(relpath, MAXPGPATH, "%s", pset.inputfile);
            get_parent_directory(relpath);
            join_path_components(relpath, relpath, filename);
            canonicalize_path(relpath);

The get_parent_directory() call reduces "foo.sql" to an empty string,
which seems a tad bogus --- wouldn't "." be better?  But in any case,
join_path_components() thinks it can process a "../" prefix of the
tail argument by stripping a directory name from the head argument,
and there's nothing there to strip.  So IMO join_path_components()
is flat-out broken when applied to a non-absolute head path.
Not sure about what a useful solution would be.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Shigeru HANADA
Date:
Subject: Re: BUG #6708: pgsql_fdw's foreign table cann't used in plpgsql function
Next
From: Josh Kupershmidt
Date:
Subject: Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../