On Tue, Jul 3, 2012 at 11:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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. =A0However,
> you seem to be using it from a script:
>
>> $ psql -aX greg -f foo.sql
>
> and then indeed it does not work so well. =A0psql is trying to evaluate
> the \ir relative to the script file's location, using this code:
>
> =A0 =A0 =A0 =A0 =A0 =A0 snprintf(relpath, MAXPGPATH, "%s", pset.inputfile=
);
> =A0 =A0 =A0 =A0 =A0 =A0 get_parent_directory(relpath);
> =A0 =A0 =A0 =A0 =A0 =A0 join_path_components(relpath, relpath, filename);
> =A0 =A0 =A0 =A0 =A0 =A0 canonicalize_path(relpath);
>
> The get_parent_directory() call reduces "foo.sql" to an empty string,
> which seems a tad bogus --- wouldn't "." be better? =A0But 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. =A0So 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=3DeW_nUH9195=3D9uPqF7=
Treg4UH7-g@mail.gmail.com
