Re: Improvements in prepared statements

From: Alejandro Sánchez <alex(at)nexttypes(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improvements in prepared statements
Date: 2021-03-01 16:08:17
Message-ID: e462a4e58ab8a2d4ff53759b6f2551f7de6dbcc4.camel@nexttypes.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


The benefit is ease of use. One of the great advantages of prepared
statements is nothaving to concatenate strings. The use of arrays would
also be very useful.
query("select " + column1 + "," + column2 from " " + table + " where id
in (?), ids);
VS
query("select # from # where id in (?)", columns, table, ids);
And it doesn't have to be done with prepared statements, it can just be
another SQL syntax.
El lun, 01-03-2021 a las 16:46 +0100, Pavel Stehule escribió:
> po 1. 3. 2021 v 16:39 odesílatel Alejandro Sánchez <
> alex(at)nexttypes(dot)com> napsal:
> > Hello, as far as I know it is not done in JDBC, in many frameworks
> > it is.Although the execution plans cannot be reused it would be
> > somethingvery useful. It is included in a lot of frameworks and is
> > a recurrentquestion in database forums. It would be nice if it was
> > included in plain SQL.
>
> I am very sceptical about it. What benefit do you expect? When you
> cannot reuse an execution plan, then there is not any benefit of
> this. Then you don't need prepared statements, and all this API is
> useless. So some questions are frequent and don't mean necessity to
> redesign. The developers just miss the fundamental knowledge of
> database technology.
>
> Regards
> Pavel
>
> > Best regards.Alejandro Sánchez.
> > El lun, 01-03-2021 a las 15:31 +0100, Pavel Stehule escribió:
> > > Hi
> > >
> > > po 1. 3. 2021 v 15:20 odesílatel Alejandro Sánchez <
> > > alex(at)nexttypes(dot)com> napsal:
> > > > Hello, some improvements in the prepared statements would
> > > > facilitate
> > > >
> > > > their use from applications:
> > > >
> > > >
> > > >
> > > > - Use of table and column names in prepared statements.
> > > >
> > > >
> > > >
> > > > Example: select # from # where # = ?;
> > > >
> > > >
> > > >
> > > > - Use of arrays in prepared statements.
> > > >
> > > >
> > > >
> > > > Example: select # from article where id in (?);
> > > >
> > > >
> > > >
> > > > # = author,title
> > > >
> > > > ? = 10,24,45
> > >
> > > The server side prepared statements are based on reusing
> > > execution plans. You cannot reuse execution plans if you change
> > > table, or column. This is the reason why SQL identifiers are
> > > immutable in prepared statements. There are client side prepared
> > > statements - JDBC does it. There it is possible. But it is
> > > impossible on the server side. Prepared statements are like a
> > > compiled program. You can change parameters, variables - but you
> > > cannot change the program.
> > >
> > > Regards
> > > Pavel
> > >
> > >
> > >
> > > >
> > > > Best regards.
> > > >
> > > > Alejandro Sánchez.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2021-03-01 16:15:02 Re: Improvements in prepared statements
Previous Message Mark Dilger 2021-03-01 16:02:27 Re: proposal: psql –help reflecting service or URI usage