Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > Tom Lane wrote:
> >> The alternative I was envisioning was to have it look at the
> >> ActivePortal's query string. However, if you prefer to define the
> >> function as returning the current client query, it's fine as-is.
> >> We should make sure the documentation explains it like that however.
>
> > Now that you told me about ActivePortal I have used that and it seems to
> > work fine. Patch attached and applied; documentation updated.
>
> 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().
As I remember, there was lots of objection to adding current_query()
because it seemed useless, but the stored procedure logic won us over,
and I assume the portal string is a better representation for that
usage. In fact, because the application knows the query string, you
could argue that anything that has more information than the client
query string is preferable.
But of course I might be wrong. ;-)
--
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
