psql line number reporting from stdin
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
Other examples for the use of the spelling "<stdin>" in this context
include gcc and slonik.
Error messages printed in interactive mode will not be affected, of
course.
Patch attached.
Attachments:
psql-stdin-lineno.patchtext/x-patch; charset=UTF-8; name=psql-stdin-lineno.patchDownload
diff --git i/src/bin/psql/common.c w/src/bin/psql/common.c
index 5ab736e..18260f1 100644
--- i/src/bin/psql/common.c
+++ w/src/bin/psql/common.c
@@ -166,6 +166,8 @@ psql_error(const char *fmt,...)
if (pset.inputfile)
fprintf(stderr, "%s:%s:" UINT64_FORMAT ": ", pset.progname, pset.inputfile, pset.lineno);
+ else if (!isatty(fileno(stdin)))
+ fprintf(stderr, "%s:<stdin>:" UINT64_FORMAT ": ", pset.progname, pset.lineno);
va_start(ap, fmt);
vfprintf(stderr, _(fmt), ap);
va_end(ap);
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
Other examples for the use of the spelling "<stdin>" in this context
include gcc and slonik.Error messages printed in interactive mode will not be affected, of
course.Patch attached.
Seems like a good idea to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Nov 28, 2011 at 8:10 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
Other examples for the use of the spelling "<stdin>" in this context
include gcc and slonik.Error messages printed in interactive mode will not be affected, of
course.Patch attached.
Seems like a good idea to me.
Naysayers can always make a case for backwards-compatibility, or not
breaking the scripts written with the existing behaviour in mind. Do our
docs have anything to say about scripts executed from stdin?
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
Naysayers can always make a case for backwards-compatibility, or not
breaking the scripts written with the existing behaviour in mind.
I'm having a hard time imagining how this could break anything. What
scenario did you have in mind?
Do our
docs have anything to say about scripts executed from stdin?
If they do, we can always update them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Nov 28, 2011 at 8:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh <singh.gurjeet@gmail.com>
wrote:Naysayers can always make a case
Should've added that I'm not one of them :)
+1 from me on the improvement.
for backwards-compatibility, or not
breaking the scripts written with the existing behaviour in mind.
I'm having a hard time imagining how this could break anything. What
scenario did you have in mind?
Probably parsing the lines that start with 'ERROR' to report that there
were errors in the script.
Do our
docs have anything to say about scripts executed from stdin?If they do, we can always update them.
At the cost of breaking existing scripts (which I am not sure is the case).
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Excerpts from Peter Eisentraut's message of sáb nov 26 17:36:15 -0300 2011:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
Not that I have ever used psql in this way, but this format is compatible
with Vim "quickfix" whereas the old one is not (not sure what Emacs
people would call this). Presumably, this being useless with <stdin> as
a file name is the reason this wasn't implemented in the first place.
+1 on the change.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Sat, 26 Nov 2011 22:36:15 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
Other examples for the use of the spelling "<stdin>" in this context
include gcc and slonik.Error messages printed in interactive mode will not be affected, of
course.Patch attached.
No issue with the change itself, but the docs claim
that
"the variant using the shell's input redirection is
(in theory) guaranteed to yield exactly the same output
you would have received had you entered everything by hand."
--
nw
On lör, 2011-11-26 at 22:36 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
It turns out that running
psql -f -
already used to print
psql:<stdin>:1: ERROR: blah
except that it got broken between 8.4 and 9.0 (commit b291c0fb), and now
prints
psql:-:1: ERROR: blah
I'll try to find a way to fix that and integrate it with the change I'm
proposing.
On lör, 2011-11-26 at 22:36 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql:<stdin>:1: ERROR: syntax error at or near "foo"
The problem is, this breaks the regression tests, because first the
actual output changes, and second the line numbers get included, which
will create a mess every time you edit a test. Not sure whether we can
work around that. Ideas?
Peter Eisentraut <peter_e@gmx.net> writes:
The problem is, this breaks the regression tests, because first the
actual output changes, and second the line numbers get included, which
will create a mess every time you edit a test. Not sure whether we can
work around that. Ideas?
Ugh, that's pretty nearly a deal-breaker. Would it be sane to have a
command line switch the regression test driver could specify to prevent
inclusion of this info?
regards, tom lane
On fre, 2011-12-09 at 13:44 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
The problem is, this breaks the regression tests, because first the
actual output changes, and second the line numbers get included, which
will create a mess every time you edit a test. Not sure whether we can
work around that. Ideas?Ugh, that's pretty nearly a deal-breaker. Would it be sane to have a
command line switch the regression test driver could specify to prevent
inclusion of this info?
Perhaps. I was thinking we could use an environment variable when
running under pg_regress. This could also help, e.g., ecpg.