Tom Lane wrote:
> I object VERY strongly to the part of the patch that inserts a
> deparse_query_list() call into exec_parse_message(). That is not a
> cheap operation, and imposing that sort of overhead on every Parse
> message is entirely unacceptable from a performance point of view.
Well, it doesn't insert a deparse_query_list() into the processing of
*every* Parse message -- it only does so for Parse messages that create
named prepared statements. I don't see that there is a fundamental
difference between a named Parse and an SQL-level PREPARE: if adding
deparse_query_list() to one is too expensive, ISTM it is too expensive
for either.
> I see no need for it either. What's wrong with regurgitating the
> original source string, which is already saved in prepared queries?
It is inconsistent to use the string supplied by the client for
protocol-level prepared statements, but to use the SQL produced by
deparsing for SQL PREPARE.
One possibility would be to execute deparse_query_list() in the SRF
(which is what Joachim's patch did originally), but that is fragile: if
a table a prepared statement depends on is dropped, the view will be
broken. We could workaround that by enclosing the deparse_query_list()
call in a PG_TRY block (and displaying a NULL query string for broken
prepared statements), but that doesn't prevent more subtle problems like
the search_path changing.
-Neil