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.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to