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 C050BD1CACB for ; Thu, 29 Jan 2004 18:38:05 +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 55545-04 for ; Thu, 29 Jan 2004 14:37:34 -0400 (AST) Received: from smtp-out6.xs4all.nl (smtp-out6.xs4all.nl [194.109.24.7]) by svr1.postgresql.org (Postfix) with ESMTP id 351A4D1B897 for ; Thu, 29 Jan 2004 14:37:33 -0400 (AST) Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.21.2]) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0TIbWiU006004 for ; Thu, 29 Jan 2004 19:37:32 +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 i0TIbVBT053718 for ; Thu, 29 Jan 2004 19:37:31 +0100 (CET) (envelope-from jtv@xs4all.nl) Received: (from jtv@localhost) by xs1.xs4all.nl (8.12.10/8.12.9/Submit) id i0TIbVJG053717 for pgsql-interfaces@postgresql.org; Thu, 29 Jan 2004 19:37:31 +0100 (CET) (envelope-from jtv) Date: Thu, 29 Jan 2004 19:37:31 +0100 From: "Jeroen T. Vermeulen" To: pgsql-interfaces@postgresql.org Subject: libpq notice processors Message-ID: <20040129183731.GI43961@xs4all.nl> Mail-Followup-To: pgsql-interfaces@postgresql.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/16 X-Sequence-Number: 4685 Is it actually required that a message passed to the notice processor end in a newline? For libpqxx it would be highly convenient if this were optional from the caller's point of view. The library itself calls the same handler sometimes. Adding the newline to an error or warning message is not only inefficient, it also introduces certain risks of failure. That's just what you don't want to have when handling an error in the first place--error handling clauses are usually the worst-tested corners of the program. Simply making the newline optional may be inconvenient for the notice processor, e.g. if it's something like fprintf(stderr,"%s",msg); (and we want to give the user maximum convenience to reduce bugs) so here's one relatively easy way to solve the problem: * The message passed to the handler "ought to" end in newline, but it doesn't always. * If the trailing newline is missing, it will be written by the next call to the notice processor. * If the original message missed its trailing newline, the next message will contain only the missing newline. Now, whenever it is inconvenient to tack a trailing newline to a message, libpqxx could call the notice processor twice--once with the message text and once with the newline. A printf-style notice processor would continue simply to print out what it's given, as before. A typical GUI notice processor, which might want to pop up a dialog for each message, can display the message regardless of trailing newline, provided it ignores messages consisting only of "\n". Jeroen