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 BC9C99DCA09; Mon, 13 Mar 2006 22:52:09 -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 19813-01; Mon, 13 Mar 2006 22:52:13 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from houston.familyhealth.com.au (houston.au.fhnetwork.com [203.22.197.21]) by postgresql.org (Postfix) with ESMTP id 655E79DC8A4; Mon, 13 Mar 2006 22:52:04 -0400 (AST) Received: from houston.familyhealth.com.au (localhost [127.0.0.1]) by houston.familyhealth.com.au (Postfix) with ESMTP id 0AE922508A; Tue, 14 Mar 2006 10:51:52 +0800 (WST) Received: from [127.0.0.1] (work-40.internal [192.168.0.40]) by houston.familyhealth.com.au (Postfix) with ESMTP id 14E472507C; Tue, 14 Mar 2006 10:51:49 +0800 (WST) Message-ID: <4416301F.9070800@familyhealth.com.au> Date: Tue, 14 Mar 2006 10:53:19 +0800 From: Christopher Kings-Lynne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tom Lane Cc: Michael Glaesemann , pgsql-patches@postgresql.org, pgsql-interfaces@postgresql.org Subject: Re: [PATCHES] Proposed patch for error locations References: <5114.1142185055@sss.pgh.pa.us> <7274.1142262691@sss.pgh.pa.us> In-Reply-To: <7274.1142262691@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-familyhealth-MailScanner-Information: Please contact the ISP for more information X-familyhealth-MailScanner: Found to be clean X-familyhealth-MailScanner-From: chriskl@familyhealth.com.au X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.098 required=5 tests=[AWL=0.098] X-Spam-Score: 0.098 X-Spam-Level: X-Archive-Number: 200603/18 X-Sequence-Number: 6074 > 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? Sounds like it'd be handy in phpPgAdmin...