Re: Improvements in prepared statements

po 1. 3. 2021 v 21:35 odesílatel Alejandro Sánchez napsal: > Using any() has the disadvantage that in JDBC it is necessary > > to create an array with connection.createArrayOf() and indicate > > the type of the array, which complicates automation. > > > With statement.setObject() you can pass any

Re: Improvements in prepared statements

Using any() has the disadvantage that in JDBC it is necessaryto create an array with connection.createArrayOf() and indicatethe type of the array, which complicates automation. With statement.setObject() you can pass any type of parameter.JDBC could add a method that doesn't need the array type. St

Re: Improvements in prepared statements

I have already implemented this in my Java project with some kind of SQL preprocessor. I leave the idea here in case more people are interested and PostgreSQL developers findit convenient to include it. It is just string concatenation but it is a sintactic sugar very useful in any SQL application.

Re: Improvements in prepared statements

Hi po 1. 3. 2021 v 17:26 odesílatel Alejandro Sánchez napsal: > It is a matter of taste. I think this functionality would be better in SQL > > and be the same for all languages without the need to use string functions. > > You can try to implement it, and send a patch. But I think a) it will be

Re: Improvements in prepared statements

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 < > a...@nexttypes.com> napsal: >

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:15 odesílatel Pavel Stehule napsal: > > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez > napsal: > >> The benefit is ease of use. One of the great advantages of prepared >> statements is not >> >> having to concatenate strings. The use of arrays would also be very usefu

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez napsal: > The benefit is ease of use. One of the great advantages of prepared > statements is not > > having to concatenate strings. The use of arrays would also be very useful. > > > query("select " + column1 + "," + column2 from " " + table +

Re: Improvements in prepared statements

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 (?)", column

Re: Improvements in prepared statements

po 1. 3. 2021 v 16:39 odesílatel Alejandro Sánchez 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 something > > very useful. It is included in a lot of frameworks and is a recurrent >

Re: Improvements in prepared statements

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. Best regard

Re: Improvements in prepared statements

Hi po 1. 3. 2021 v 15:20 odesílatel Alejandro Sánchez 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 pre

Improvements in prepared statements

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 (?);