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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Date: 2008-07-21 14:31:04
Message-ID: 13126.1216650664@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Markus Wanner <markus(at)bluegap(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Markus Wanner 2008-07-21 14:55:10 Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Previous Message User Mkz 2008-07-21 14:06:18 plproxy - plproxy: v2.0.6rc2

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-07-21 14:41:25 Re: WITH RECUSIVE patches 0721
Previous Message Grzegorz Jaśkiewicz 2008-07-21 14:29:09 Re: overlaps performance