Re: Proposed patch for error locations
От | Tom Lane |
---|---|
Тема | Re: Proposed patch for error locations |
Дата | |
Msg-id | 7274.1142262691@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposed patch for error locations (Michael Glaesemann <grzm@myrealbox.com>) |
Ответы |
Re: Proposed p.tch for error locations
Re: Proposed patch for error locations |
Список | pgsql-patches |
[ cross-posting to pgsql-interfaces in hopes of drawing more comments ] Michael Glaesemann <grzm@myrealbox.com> writes: > On Mar 13, 2006, at 2:37 , Tom Lane wrote: >> http://archives.postgresql.org/pgsql-patches/2006-03/msg00153.php > This looks really nice. >> One thing I'm noticing already is that the addition of "at character N" >> to a lot of these messages isn't an improvement. In psql it's >> certainly redundant with the error-cursor display. > The pure character count is definitely difficult to use with larger > queries. I think it could be more useful if it were > line:char_of_line. Would others find this useful? The change in behavior would actually be in libpq, because it's PQerrorMessage that is doing the deed (assuming a reasonably modern server and libpq). What I was considering proposing was that we migrate the error-cursor feature out of psql and into PQerrorMessage. This would mean that you'd get responses like ERROR: column "foo" does not exist LINE 1: select foo from a; ^ from all libpq-using applications not just psql. We could make this conditional on the error verbosity --- in "terse" mode the "LINE N" output wouldn't appear, and "at character N" still would. Applications should already be expecting multiline outputs from PQerrorMessage if they're in non-terse mode, so this ought to be OK. Comments? regards, tom lane
В списке pgsql-patches по дате отправления: