Re: [GENERAL] Suggested "minor" change to psql - Mailing list pgsql-hackers

From Brook Milligan
Subject Re: [GENERAL] Suggested "minor" change to psql
Date
Msg-id 199912081854.LAA14035@biology.nmsu.edu
Whole thread Raw
List pgsql-hackers
When I develop a new DB schema using psql, I usually first create a file, say  "mySchema.sql". I then "createdb" the
database,start up psql, and use the  command "\i mySchema.sql" to load in my new schema. There will be, needless to
say,several errors.  These fall nicely below the offending line and I can look  at fixing them. I drop the DB, re-edit
mySQL file and re-do the "\i" command.
 

I think the new stuff allows separating or merging different output
"channels" so that psql can be run in the different ways you wish.

However, this does raise another issue that might make debugging
scripts run through psql easier.  I have found that emacs compile
buffer semantics are extremely useful for debugging source code, and
suggest that error messages from psql follow something similar (at
least as an option) to aid in script debugging.  The output of
compiler error messages generally gives a filename:linenumber prefix
to the message; emacs can parse that an put you exactly at the correct
point for fixing the error.

If psql would also output messages in the same form, i.e.,
  filename:linenumber: error message

then scripts run in emacs compile buffer (easily done either directly
or with make) could be rapidly debugged using the normal mechanisms
available for "normal" source code debugging.

I realize that everyone does not use emacs, but I can't see how
including that information would be detrimental to anyone.  It gives
more information useful for anyone debugging scripts.

Cheers,
Brook


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY andshift/reduce)
Next
From: Ed Loehr
Date:
Subject: Re: [HACKERS] Raising funds for PostgreSQL