DevHeads.net

31.11. Notice Processing - associating notices with calls

By Pawel at 06/25/2012 - 05:10

Hi.

What's the best way to "associate" an incoming notice with the statement
that resulted in generating it? Notice operate on PGResult objects, but
these objects only become available after the statement call is made.
Should I have a global (or thread global, since my app is MT) "flag" that
would tell the receiver what statement was executed last? I assume that the
execution path is that notice call back is invoked while the statement
function executes.

Thank you,
Pawel.

Comments

Re: 31.11. Notice Processing - associating notices wit

By Tom Lane at 06/25/2012 - 11:07

Pawel Veselov <pawel. ... at gmail dot com> writes:
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.

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).

regards, tom lane

Re: 31.11. Notice Processing - associating notices wit

By Pawel at 06/25/2012 - 14:00

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.

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