From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: In what range of the code can we read debug_query_string? |
Date: | 2018-05-25 14:08:08 |
Message-ID: | 3389.1527257288@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> It is set for other kinds of message, (parse, bind, execute). I
> think fastpath, close, flush and sync don't need that. If it is
> reasonable to assume that we can see debug_query_string in the
> DESCRIBE path, the attached patch would work.
I think this patch is a bad idea. In the first place, debug_query_string
is generally understood as the current *client* command string, not
something internally generated. In the second place, it looks way too
easy for this to leave debug_query_string as a dangling pointer,
ie pointing at a dropped plancache entry.
There might be a case for providing some way to get at the current
actively-executing query's string, using a protocol that can deal
with nesting of execution. (This might already be more or less
possible via ActivePortal->sourceText, depending on what you think
the semantics ought to be.) But debug_query_string was never
intended to do that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-05-25 14:11:49 | Re: Enhancement Idea - Expose the active value of a parameter in pg_settings |
Previous Message | Robert Haas | 2018-05-25 14:06:00 | rule-related crash in v11 |