X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 048DAD1C46E for ; Fri, 30 Jan 2004 11:54:44 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 89110-05 for ; Fri, 30 Jan 2004 07:54:46 -0400 (AST) Received: from smtp-out2.xs4all.nl (smtp-out2.xs4all.nl [194.109.24.12]) by svr1.postgresql.org (Postfix) with ESMTP id 279BCD1BB52 for ; Fri, 30 Jan 2004 07:54:43 -0400 (AST) Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.21.2]) by smtp-out2.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0UBsdjT041932; Fri, 30 Jan 2004 12:54:44 +0100 (CET) Received: from xs1.xs4all.nl (jtv@localhost.xs4all.nl [127.0.0.1]) by xs1.xs4all.nl (8.12.10/8.12.9) with ESMTP id i0UBsdBT020599; Fri, 30 Jan 2004 12:54:39 +0100 (CET) (envelope-from jtv@xs4all.nl) Received: (from jtv@localhost) by xs1.xs4all.nl (8.12.10/8.12.9/Submit) id i0UBsUZA020592; Fri, 30 Jan 2004 12:54:30 +0100 (CET) (envelope-from jtv) Date: Fri, 30 Jan 2004 12:54:30 +0100 From: "Jeroen T. Vermeulen" To: Tom Lane Cc: pgsql-interfaces@postgresql.org Subject: Re: libpq notice processors Message-ID: <20040130115430.GC19680@xs4all.nl> Mail-Followup-To: Tom Lane , pgsql-interfaces@postgresql.org References: <20040129183731.GI43961@xs4all.nl> <26188.1075403259@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26188.1075403259@sss.pgh.pa.us> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/18 X-Sequence-Number: 4687 On Thu, Jan 29, 2004 at 02:07:39PM -0500, Tom Lane wrote: > > If we were going to demand a change in notice processors, I'd think the > better approach is just to state that the notice text may or may not end > in a newline, and the hook routine should strip or add one as it wishes. > This is less of a change conceptually than splitting a single logical > message across multiple calls. But I disagree with changing the API at > all. Fair enough.