Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../

On Tue, Jul 3, 2012 at 11:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> jgd(at)well(dot)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.

I may not have time to look at this today, but I think this behavior
worked fine in the last version[1] of Gurjeet's \ir patch which I
reviewed, which had different behavior for pathname normalization than
what got committed.

Josh

[1] http://archives.postgresql.org/message-id/BANLkTi=eW_nUH9195=9uPqF7Treg4UH7-g@mail.gmail.com