Обсуждение: Re: [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
--On Tuesday, June 24, 2003 14:07:23 -0700 Joe Conway <mail@joeconway.com> 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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.
regards, tom lane
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
Added to TODO: * Promote debug_query_string into a server-side function current_query() --------------------------------------------------------------------------- Joe Conway wrote: > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> 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