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

libpq notice processors

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: libpq notice processors
Date: 2004-01-29 18:37:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
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".


pgsql-interfaces by date

Next:From: Tom LaneDate: 2004-01-29 19:07:39
Subject: Re: libpq notice processors
Previous:From: stella DEFODate: 2004-01-29 16:09:36
Subject: Demande d'aide sur la connection de postgresql à pgaccess

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