Re: [GENERAL] capturing and storing query statement with - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [GENERAL] capturing and storing query statement with
Date
Msg-id 3EF9B88D.80803@joeconway.com
Whole thread Raw
In response to Re: [GENERAL] capturing and storing query statement with rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] capturing and storing query statement with  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>I was thinking something similar. This exact question has come up at 
>>least three times in the last three months. I doubt we'd want a special 
>>keyword like CURRENT_QUERY, but maybe current_query()?
> 
> Not unless you want to promote a quick debugging hack, not expected or
> required to work 100%, into a supported feature.  I don't think
> debug_query_string can be relied on to always reflect what the system
> is doing, particularly not in the 3.0 protocol extended-query case.
> And how about when you're executing queries inside a function --- is it
> supposed to tell you about the most closely nested SQL query?
> 
> I don't say this is not worth doing --- but I do say you are opening a
> larger can of worms than you probably think.
> 

Hmmm. Good points. This one may best wait for 7.5 at least. Does it make 
sense to turn it into a TODO?
 * promote debug_query_string into a documented, supported feature

Anyone who *does* use the function from dblink, please be sure to report 
circumstances where dblink_current_query() returns something other than 
what you would expect.

Thanks,

Joe



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: RServ patch to support multiple slaves (sorta)
Next
From: Bruce Momjian
Date:
Subject: Re: RServ patch to support multiple slaves (sorta)