On Tue, Jul 3, 2012 at 11:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > j...@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.
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=9upqf7treg4uh...@mail.gmail.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
