Re: [HACKERS] [GENERAL] capturing and storing query statement with
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Joe Conway 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()? > The current statement can be examined using the statistics views and > functions. That's not very reliable though --- unless the current query has been running for quite a few milliseconds, there's no guarantee it will be reflected in the statistics collector's output. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] capturing and storing query statement with
Joe Conway 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()? The current statement can be examined using the statistics views and functions. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] capturing and storing query statement with
Added to TODO: * Promote debug_query_string into a server-side function current_query() --- Joe Conway wrote: > Tom Lane wrote: > > Joe Conway <[EMAIL PROTECTED]> 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 > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] capturing and storing query statement with
Tom Lane wrote: Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] capturing and storing query statement with rules
Joe Conway <[EMAIL PROTECTED]> 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. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] capturing and storing query statement with
--On Tuesday, June 24, 2003 14:07:23 -0700 Joe Conway <[EMAIL PROTECTED]> wrote: (moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? 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()? Comments? I was thinking the same thing. Currently I use the contrib/dblink supplied function, but a firstclass, in the default install, version would be nice. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] capturing and storing query statement with rules
(moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? 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()? Comments? Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
