Re: [GENERAL] 31.11. Notice Processing - associating notices with calls
On Mon, Jun 25, 2012 at 8:07 AM, Tom Lane wrote: > Pawel Veselov 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?
Re: [GENERAL] 31.11. Notice Processing - associating notices with calls
Pawel Veselov 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 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.
