It is a matter of taste. I think this functionality would be better in
SQLand be the same for all languages without the need to use string
functions.
El lun, 01-03-2021 a las 17:15 +0100, Pavel Stehule escribió:
> po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez <
> alex(at)nexttypes(dot)com> napsal:
> > 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.
>
> This is not too strong an argument - any language (and Database API)
> has necessary functionality now. Just you should use it.
>
> You can use fprintf in php, format in plpgsql, String.Format in C#,
> Java, ...
>
> Regards
>
> Pavel
>
>
>
>
> > 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.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >