Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Proposed p.tch for error locations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Michael Glaesemann <grzm(at)myrealbox(dot)com>, pgsql-patches(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: [PATCHES] Proposed p.tch for error locations
Date: 2006-03-13 21:28:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfacespgsql-patches
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


			regards, tom lane

In response to

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2006-03-14 02:53:19
Subject: Re: [PATCHES] Proposed patch for error locations
Previous:From: Neil ConwayDate: 2006-03-13 18:05:19
Subject: Re: Fix syntax errors in contrib uninstall scripts

pgsql-interfaces by date

Next:From: Fangbing WuDate: 2006-03-14 01:25:46
Subject: Inherits and triggers
Previous:From: Milen DzhumerovDate: 2006-03-13 18:27:38
Subject: Compiling/Linking on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group