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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
