pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Proposed p.tch for error locations
5+ messages / 2 participants
[nested] [flat]
* Re: Proposed p.tch for error locations
@ 2006-03-13 15:32 Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 2 replies; 5+ messages in thread
From: Alvaro Herrera @ 2006-03-13 15:32 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Glaesemann <grzm@myrealbox.com>; pgsql-patches@postgreSQL.org; pgsql-interfaces
Tom Lane wrote:
> 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;
> ^
This doesn't work on terminal using a variable-width font, does it?
Sure, you can have all the interfaces use a monospace font, but it seems
a weird thing to do. I think the line/character position should be
returned in a separate error attribute in ereport. So for example
pgAdmin could count characters and mark it in bold or use a different
color.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Proposed p.tch for error locations
@ 2006-03-13 15:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@commandprompt.com>
1 sibling, 1 reply; 5+ messages in thread
From: Tom Lane @ 2006-03-13 15:57 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Michael Glaesemann <grzm@myrealbox.com>; pgsql-patches@postgreSQL.org; pgsql-interfaces
Alvaro Herrera <alvherre@commandprompt.com> writes:
> This doesn't work on terminal using a variable-width font, does it?
> Sure, you can have all the interfaces use a monospace font, but it seems
> a weird thing to do. I think the line/character position should be
> returned in a separate error attribute in ereport. So for example
> pgAdmin could count characters and mark it in bold or use a different
> color.
That information is already available to pgAdmin, and has been since
7.4; if they are failing to exploit it that's their problem not libpq's.
Basically what's at stake here is the behavior of "dumb" applications
that are just using PQerrorMessage and not doing anything smart with
error message fields. It does not seem unreasonable to me to assume
fixed-width font in that context. We haven't seen any complaints about
psql doing it have we?
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Proposed p.tch for error locations
@ 2006-03-13 16:03 Alvaro Herrera <alvherre@commandprompt.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Alvaro Herrera @ 2006-03-13 16:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Glaesemann <grzm@myrealbox.com>; pgsql-patches@postgreSQL.org; pgsql-interfaces
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > This doesn't work on terminal using a variable-width font, does it?
> > Sure, you can have all the interfaces use a monospace font, but it seems
> > a weird thing to do. I think the line/character position should be
> > returned in a separate error attribute in ereport. So for example
> > pgAdmin could count characters and mark it in bold or use a different
> > color.
>
> That information is already available to pgAdmin, and has been since
> 7.4; if they are failing to exploit it that's their problem not libpq's.
Aye, that's fine. I don't really know if pgAdmin uses the info or not.
I thought the proposal to remove the "at character N" in the error
message meant that the only way to get that information would be from
the "LINE Y: ...\n[some whitespace]^" message, which would be pretty
cumbersome. But if there already is a field in the error message for
the position, then nothing is lost.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Proposed p.tch for error locations
@ 2006-03-13 16:08 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2006-03-13 16:08 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Michael Glaesemann <grzm@myrealbox.com>; pgsql-patches@postgreSQL.org; pgsql-interfaces
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> That information is already available to pgAdmin, and has been since
>> 7.4; if they are failing to exploit it that's their problem not libpq's.
> Aye, that's fine. I don't really know if pgAdmin uses the info or not.
> I thought the proposal to remove the "at character N" in the error
> message meant that the only way to get that information would be from
> the "LINE Y: ...\n[some whitespace]^" message, which would be pretty
> cumbersome.
You should reflect on the fact that psql is currently generating that
line from outside libpq ...
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCHES] Proposed p.tch for error locations
@ 2006-03-13 21:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@commandprompt.com>
1 sibling, 0 replies; 5+ messages in thread
From: Tom Lane @ 2006-03-13 21:28 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Michael Glaesemann <grzm@myrealbox.com>; pgsql-patches@postgresql.org; pgsql-interfaces
I took another look at this and realized that for PQerrorMessage to emit
a cursor-pointer line, it'd be necessary for libpq to hold onto a copy
of the query last sent, which it doesn't do presently. This is annoying
for long queries --- in the worst case it could provoke out-of-memory
failures that don't occur now.
Plan B would be for psql to stop using PQerrorMessage and generate the
message report text from the message fields, omitting "at character N".
This would require duplicating a couple dozen lines from inside libpq.
It'd also mean that the report text gets built twice, once inside libpq
and once by psql, which is probably not such a big deal since error
messages ought not be a performance-critical path ... except there's
still that little question of overrunning memory.
Plan C is just to drop the "at character N" string from what
PQerrorMessage generates. We could make this configurable (maybe via
additional PGVerbosity values), or just not worry about whether it's
important.
Thoughts?
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2006-03-13 21:28 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-13 15:32 Re: Proposed p.tch for error locations Alvaro Herrera <alvherre@commandprompt.com>
2006-03-13 15:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-03-13 16:03 ` Alvaro Herrera <alvherre@commandprompt.com>
2006-03-13 16:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-03-13 21:28 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox