Neil Conway <neilc@samurai.com> writes:
> 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 quite agree ;-)
> 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.
Arguably, deparsing when the view is read is the only correct way to
handle search-path changes. But I really think that storing the source
string is the most useful as well as fastest definition. 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.
regards, tom lane
