Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Well, hold on a minute.  I said that was an alternative to look at,
> >> not that it was necessarily better.  Can you define in words of one
> >> syllable which queries will be exposed this way?  I don't believe
> >> it's "all of them".
> 
> > Well, if you call a pl function, it is going to show you the current SPI
> > function running rather than the user query.  Because the comment next
> > to the function says:
> 
> >      *  Expose the current query to the user (useful in stored procedures)
> 
> > I assume the portal string is better for stored procedures then
> > debug_query_string for current_query().
> 
> Uh, no, not necessarily.  As an example, if the thing were really
> returning the most closely nested query (I'm not sure it is) then
> a plpgsql function trying to inspect the value of current_query()
> would always get back the result "SELECT current_query()".  Not
> too helpful, eh?  So we actually do have to think a little bit
> about exactly *which* query we want to return and whether the
> ActivePortal can be counted on to be that one.

I thought they would be calling this via some function call fastpath but
I can see it being used in SQL functions, now that you mention it.

OK, reverted, but I added a comment we might want to use
ActivePortal->sourceText.

> The good thing about using debug_query_string is that "the current
> client query" is well-defined and easy to explain.  I'm worried
> whether using ActivePortal isn't likely to result in a rather
> implementation-dependent behavior that changes from release to release.
> 
> Or maybe it really is the Right Thing ... but I'm not feeling
> confident of that.

Agreed.  

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +