Re: Prepared statements considered harmful

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prepared statements considered harmful
Date: 2006-08-31 18:58:48
Message-ID: 22704.1157050728@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Gregory Stark wrote:
>> Driver interfaces expose very clearly to the user an explicit
>> interface to prepare and execute a query separately.

> The JDBC documentation merely contains statements of the sort "A SQL
> statement with or without IN parameters can be pre-compiled and stored
> in a PreparedStatement object. This object can then be used to
> efficiently execute this statement multiple times." There is
> absolutely no indication that the execution plan of the statement is
> computed at the time of preparation.

The key word there is "efficiently". I think it is a reasonable
presumption on the user's part that a query done this way will have less
overhead than just resubmitting the raw query each time.

The important thing I see here is that JDBC allows use of IN parameters
with or without a PreparedStatement (no?). So they've separated the
concepts of out-of-line parameters and "preparing" a statement. That's
the distinction we have unfortunately fudged in the V3 protocol.

The protocol does let you use OOL parameters without retaining a
prepared plan, thanks to the hack introduced later to not plan the
unnamed statement at Parse time, but that's definitely a bit of a wart
on the original protocol design. Maybe it's good enough, or maybe not.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-08-31 19:06:06 Re: [pgsql-advocacy] Thought provoking piece on NetBSD
Previous Message Bruce Momjian 2006-08-31 18:57:41 Re: [HACKERS] Interval aggregate regression failure