Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Дата
Msg-id 13126.1216650664@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the  (Markus Wanner <markus@bluegap.ch>)
Ответы Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the  (Markus Wanner <markus@bluegap.ch>)
Список pgsql-hackers
Markus Wanner <markus@bluegap.ch> writes:
> This commit added a variable 'query_string' to the function 
> ExecuteQuery() in src/backend/commands/prepare.c, but that function 
> already takes an argument named 'queryString'. What's the difference? 
> Which is which? Do we need both?

The query_string variable is the original PREPARE's query_string copied
into the portal's context, which we do to ensure that it lives as long
as the portal does.  There's no guarantee that the CachedPlanSource
will survive that long (there could be a DEALLOCATE while the query
executes).

The one passed in is the query string for the EXECUTE statement.
I think it's just used for error reporting in EvaluateParams.

> I propose renaming the variable (as in the attached patch) or at least 
> explaining it better in additional comments.

This seems like a bad idea, because it makes the code gratuitously
different from the names used for this purpose everywhere else.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Grzegorz Jaśkiewicz
Дата:
Сообщение: Re: overlaps performance
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: WITH RECUSIVE patches 0721