Thank you for the comment.
At Fri, 25 May 2018 10:08:08 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <3389.1527257288@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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.
I agree on the CachedPlanGetTargetList (Describe-Portal) case.
> In the first place, debug_query_string
> is generally understood as the current *client* command string, not
> something internally generated.
Ture. It is commented on the variable, and I see bind and execute
restore the prepared statement (string) to the variable while
processing on the other hand. So my core question here is whether
the same reasoning is applicable on describe_statement. Execute
returns the result of a statement, and describe returns the
input/output description for the same statement these are
different only in what they returns for the same query.
> 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.
exec_bind_message uses CachedPlanSource.plansource for
debug_query_string. If the describe_statement case is problematic
in the way, is exec also problematic in the same way?
> 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.
I'm not sure of for what purpose the describe_statement is used,
but exec_execute_messages seems doing exactly that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
