Tom Lane wrote:
> The average application that wants to use this view at all will be
> looking to see "did I already prepare FOO". If it's using the query
> definition string for this purpose, comparing source text is easy
> while comparing deparsed text to source is a nightmare.
Well, I don't see why an application would want to look at the query
string in the first place -- as you pointed out earlier, using the
prepared statement's name seems a much easier way to identify prepared
statements.
In any case, if we use the query string as supplied by the user, how do
we produce that string in the case of SQL PREPARE? Manually stripping a
"PREPARE ... AS" prefix from the query string is difficult to do
robustly, but it seems (a) expensive (b) inconsistent to deparse the
Query for SQL PREPARE but not for Parse messages. We could just include
the "PREPARE ... AS" prefix for SQL PREPAREs, but that seems ugly.
-Neil
