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

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

Hi,

Tom Lane wrote:
> Adjust things so that the query_string of a cached plan and the sourceText of
> a portal are never NULL, but reliably provide the source text of the query.
> It turns out that there was only one place that was really taking a short-cut,
> which was the 'EXECUTE' utility statement. That doesn't seem like a
> sufficiently critical performance hotspot to justify not offering a guarantee
> of validity of the portal source text....

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?

It looks like the second is the query string of the prepare statement,
where the string passed as an argument contains the EXECUTE command. I
propose renaming the variable (as in the attached patch) or at least
explaining it better in additional comments.

Sorry, if this is nitpicking. I just happened to stumbled over it and
thought I better tell you.

Regards

Markus

Attachment Content-Type Size
prepare.renaming.diff text/x-diff 1.7 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message User Mkz 2008-07-21 11:33:14 pgbouncer - pgbouncer: test/Makefile: add DEFS to cflags
Previous Message Tom Lane 2008-07-21 04:47:00 pgsql: Code review for array_fill patch: fix inadequate check for array

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2008-07-21 11:46:39 Re: pg_dump additional options for performance
Previous Message Grzegorz Jaśkiewicz 2008-07-21 11:08:50 overlaps performance