FE/BE protocol vs. parameterized queries - Mailing list pgsql-hackers

From Andrew - Supernews
Subject FE/BE protocol vs. parameterized queries
Date
Msg-id slrnefp5c0.2ea3.andrew+nonews@atlantis.supernews.net
Whole thread Raw
Responses Re: FE/BE protocol vs. parameterized queries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Picking out a specific point from the thread on prepared queries:

Currently, the handling of Parse/Bind on the unnamed statement seems to
go like this:
 - Parse on the unnamed statement does analysis and rewriting but does   not plan, storing the query in a special
memorycontext dedicated to   the unnamed statement
 
 - Bind on the unnamed statement plans the query (using the supplied   parameters) and stores the plan back in the
unnamedstatement's context
 

I believe this could usefully (and transparently to clients) be changed
so that Bind on the unnamed statement does _not_ store the plan back in
the unnamed statement's context, but instead produces a plan which is
only used _for that specific portal_. Thus, it would promote the parameters
to constants before planning, knowing that the plan could only be run once;
this would, I believe, allow the planner to produce a plan that was
equivalent to that of a non-parameterized query.

This would hopefully remove all cases where it is currently necessary to
use PQexec rather than PQexecParams, such as where parameterized limits,
immutable functions of parameters, partial indexes etc. are involved.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: [COMMITTERS] pgsql: sslinfo contrib module -
Next
From: Tom Lane
Date:
Subject: Re: FE/BE protocol vs. parameterized queries