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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
