On Apr 8, 9:20 am, paddor <[email protected]> wrote: > Hi > > When using prepared statements with PostgreSQL, I don't like having to > specify all bound variables of a table manually.
I'm sorry, but that's how it works. > Why doesn't it just use all colums of this table to create the > prepared statement? It could simply use the column names as the bound > variable names. And why this strange :$name syntax described on [1]? > I'm totally confused by this manual page because sometimes it uses :n, > other times :$name and other times :name. Which one was the bound > variable again? Which one is the name used later in the Ruby code? The only columns it could possibly use are the columns you are referencing in the query, which in most cases are a small subset of all of the columns in the table. The strange :$syntax was chosen because bound variable/prepared statement support was added fairly late in Sequel's development (2.4.0), it was the best way I could think of to allow the use of bound variables and prepared statements while keeping Sequel's method chaining API and not negatively affecting backwards compatibility. If you are confused by when to use :$name vs. :name, note that :$name is only used to specify the bound variable placeholders themselves. The values of the placeholders are provided with the regular :name syntax. To take an example from [1]: ds = DB[:items].filter(:name=>:$n) ds.call(:select, :n=>'Jim') Here :$n is used as the placeholder, and :n is used to provide the value of the placeholder. I guess I'm not clear on what is confusing you. > And as for the type specifiers: Sequel already knows about the column > types. It can retrieve them from the database as it does like in a > Model. Actually, it wouldn't be able to do so in an unambiguous manner except in very simple cases, and even though it would a major effort to try to support. In a Model, Sequel knows exactly what the columns are for the model's backing table. There is no such knowledge with datasets. Note that you should only be attempting to use bound variables and prepared statements if you have identified a bottleneck in your application that you think preparing will speed up. Generally, only queries that are complex for the database to plan stand much benefit from preparing, and those queries tend to be the most complex ones. Using bound variables and prepared statements for simple queries in Sequel is usually slower than just embedding the value in the SQL string. I've done benchmarking on this on PostgreSQL, if you are interested [2]. Jeremy [2] http://groups.google.com/group/sequel-talk/browse_thread/thread/89984f67b8ccedf3/cd29c89012da82fc?lnk=gst&q=postgresql+bound+variables#cd29c89012da82fc -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
