Re: 31.11. Notice Processing - associating notices with calls - Mailing list pgsql-general

From Pawel Veselov
Subject Re: 31.11. Notice Processing - associating notices with calls
Date
Msg-id CAMnJ+BcyC+0ReG=9nbuQumk2SfcSw5Q0tOnq9Mq0i7za3Fxp6w@mail.gmail.com
Whole thread Raw
In response to Re: 31.11. Notice Processing - associating notices with calls  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general

On Mon, Jun 25, 2012 at 8:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pawel Veselov <pawel.veselov@gmail.com> writes:
> What's the best way to "associate" an incoming notice with the statement
> that resulted in generating it?

Um ... the first issue with this problem statement is the assumption
that there *is* a statement that caused the notice.  The server is
capable of generating notices autonomously, for example during a forced
database shutdown.  But having said that, you could certainly keep track
of which command you last issued.

Is there then any way to know if a notice came from a statement? My issue is that there are some statements that generate notices that I can safely dismiss (CREATE something IF NOT EXISTS), but I don't want to dismiss any other. I believe notices are not asynchronous (I don't use any asynchronous API), so if there is a pending notice on the connection, and if I set the "current" statement, and execute it, I will first get the pending notice, and only then the statement-related notice.
 

> Notice operate on PGResult objects, but
> these objects only become available after the statement call is made.

I think you are misunderstanding the notice receiver API.  The PGresult
that's passed to the receiver is just a transient one created to hold
the notice message's fields.  It has nothing to do with the PGresult
generated to hold the eventual result of the current query (if any).

Yes, I did misunderstand it. Is there a "standard" of what would be in this result object?

pgsql-general by date:

Previous
From: pandorino
Date:
Subject: Re: pgstat wait timeout : permission denied
Next
From: Eduardo Morras
Date:
Subject: UFS2 Snapshots and Postgres