Tom Lane wrote: > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
