From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jgd(at)well(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6715: 9.2b2 psql \ir does not understand leading ../ |
Date: | 2012-07-04 06:41:46 |
Message-ID: | 9781.1341384106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | runner.mei | 2012-07-04 14:03:42 | BUG #6716: memory of Autovacuum leak? |
Previous Message | Shigeru HANADA | 2012-07-04 03:07:04 | Re: BUG #6708: pgsql_fdw's foreign table cann't used in plpgsql function |