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.

On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmail(dot)com> wrote:

> On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(dot)gurjeet(at)gmail(dot)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(at)gmail(dot)com> wrote:

> On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)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(at)commandprompt(dot)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(at)gmx(dot)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(at)gmx(dot)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.