X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id A02089DCD90; Mon, 13 Mar 2006 17:28:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 65576-10; Mon, 13 Mar 2006 17:28:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 389C19DCCE6; Mon, 13 Mar 2006 17:28:40 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k2DLScU9010459; Mon, 13 Mar 2006 16:28:38 -0500 (EST) To: Alvaro Herrera cc: Michael Glaesemann , pgsql-patches@postgresql.org, pgsql-interfaces@postgresql.org Subject: Re: [PATCHES] Proposed p.tch for error locations In-reply-to: <20060313153209.GA15002@surnet.cl> References: <5114.1142185055@sss.pgh.pa.us> <7274.1142262691@sss.pgh.pa.us> <20060313153209.GA15002@surnet.cl> Comments: In-reply-to Alvaro Herrera message dated "Mon, 13 Mar 2006 11:32:09 -0400" Date: Mon, 13 Mar 2006 16:28:38 -0500 Message-ID: <10458.1142285318@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.112 required=5 tests=[AWL=0.112] X-Spam-Score: 0.112 X-Spam-Level: X-Archive-Number: 200603/16 X-Sequence-Number: 6072 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