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. +
