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

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Date
Msg-id 13126.1216650664@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the  (Markus Wanner <markus@bluegap.ch>)
List 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 by date:

Previous
From: Grzegorz Jaśkiewicz
Date:
Subject: Re: overlaps performance
Next
From: "Pavel Stehule"
Date:
Subject: Re: WITH RECUSIVE patches 0721