Thread: 31.11. Notice Processing - associating notices with calls
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.
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.
> 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).
regards, tom lane
On Mon, Jun 25, 2012 at 8:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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?
Pawel Veselov <pawel.veselov@gmail.com> writes:Um ... the first issue with this problem statement is the assumption
> What's the best way to "associate" an incoming notice with the statement
> that resulted in generating it?
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.
I think you are misunderstanding the notice receiver API. The PGresult
> Notice operate on PGResult objects, but
> these objects only become available after the statement call is made.
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?