Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <br...@momjian.us> writes:
> > > Right now, log_error_verbosity displays the source code error location
> > > in this format:
> >
> > > LOCATION: parserOpenTable, parse_relation.c:858
> >
> > > I think it would be clearer to add '()' next to the function name. We
> > > use '() to display function names in our docs and I think using '()'
> > > would clarify the output, e.g.:
> >
> > > LOCATION: parserOpenTable(), parse_relation.c:858
> >
> > Seems like a waste of log space to me. The convention about writing ()
> > to decorate function names is hardly universal, and anyway it's mainly
> > useful to mark things that the reader might not realize are function
> > names. This can't be anything else.
>
> I suggested it because it wasn't obvious to me it was a function name,
> so I figured others might not recognize it. Remember, we deal with the
> C code all the time so we have to consider how the general user would
> see it.
FYI, here is the output that had me confused:
ERROR: 42P01: relation "lkjasdf" does not exist at character 15
LOCATION: parserOpenTable, parse_relation.c:858
STATEMENT: select * from lkjasdf;
Without the '()', I thought the LOCATION related to the query error
location, not the source code error location. This is what the new
format would look like, which I think is clearer:
ERROR: 42P01: relation "lkjasdf" does not exist at character 15
LOCATION: parserOpenTable(), parse_relation.c:858
STATEMENT: select * from lkjasdf;
Of course, maybe the word LOCATION is wrong and it should be FUNCTION:
ERROR: 42P01: relation "lkjasdf" does not exist at character 15
FUNCTION: parserOpenTable(), parse_relation.c:858
STATEMENT: select * from lkjasdf;
or SOURCE:
ERROR: 42P01: relation "lkjasdf" does not exist at character 15
SOURCE: parserOpenTable(), parse_relation.c:858
STATEMENT: select * from lkjasdf;
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
