On Mon, Jun 25, 2012 at 8:07 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Pawel Veselov <pawel.vese...@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?
