On Dec 10, 2007, at 2:55 PM, Mathieu Bouchard wrote: > On Mon, 10 Dec 2007, Jamie Bullock wrote: >> On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: >>> This almost *never* happens. >> I take your point, but I think you are exaggerating slightly. > > Not in this context. We're only looking at the average query; I > don't even mean an actual query, but statistics about queries. If > only 10% of them don't have arguments, then unless there's a huge > difference in object count (which there is not), it doesn't make > much of a difference on the total object count. And that is only > supposing that you need something like an extra [bang] before your > sql query to prevent [psql] from getting non-bang messages. > >> I just looked at the code for a database driven web app I worked >> on recently. It uses 30 queries, 3 of which have no variables. Out >> of these three only one doesn't 'overlap' with other queries and >> therefore can't be refactored. Maybe 1 in 30 is almost never? > > Yes. to contrast this, 3% wouldn't be "almost never" if, for > example, the issue was whether to support something at all, or not. > In that case, if the cost of a workaround is 50x the wanted > feature, or if a workaround is impossible, it can weigh a lot in > the design priorities. > >> Good point! I think Hans' recent suggestion addresses the problem. It >> also occurs to me that for Postgres at least, we have the PREPARE >> statement, which addresses the optimisation and injection issues you >> have raised. Technically [psql] already supports PREPARE except that >> PREPARE uses the '$' character as its placeholder identifier, and >> '$1' >> can't be passed around as a symbol in Pd. I think it might be >> interesting to use the '?' notation currently under discussion as an >> interface to PREPARE though. > > The '?' notation is either MySQL-specific or PerlDBI-specific or > both. By PerlDBI I mean any database interface (in any language) > following's Perl DBI package closely enough. I guess that if you > use DBI-over-Postgres, then it replaces all ? by $ automatically.
The other somewhat common style that I saw in my searches was printf patterns (%s, %f, etc). In Pd, [makefilename], [makesymbol], [sprintf], and perhaps others use this syntax. The single ? notation seems to be supported by at least these, if you want to call that "specific": Qt, PerlDBI, Perl's DBD::Pg, RubyDBI, PHP PDO, Java JDBC, MySQL, Oracle. I think it is quite important to reuse existing syntax rather than introducing new syntax. Minimal syntax is really one of Pd's biggest strengths. Since these lines would be pure SQL, I think it would be appropriate to use a common SQL syntax. I just had a thought, SQL injection relies on being able to send semi- colons in text fields. You can't transmit a semicolon in a message in Pd, and if you don't provide a means to explicitly send a semi- colon to the query (e.g. [addsemi( to the hot inlet), then no one will ever be able to send a semi-colon to [sqlite]/[psql]. Pd would always interpret the semi-colon before the object received it on its cold inlet. AFAIK, that eliminates basically all of the really bad SQL injection attacks. .hc > > $ alone can be used in pd as long as it is not followed by a digit, > but I wouldn't encourage that, if it's not used in a [expr] way, > because the use of '$' alone would prevent you from later > supporting an [expr] syntax in a way compatible with yourself. > > Using $f1 or $s1 in [expr] style, or perhaps $e1 to mean "any > atom" (e stands for "element"), would be useful, though less > required than the placeholder feature itself. > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC > Canada_______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- http://at.or.at/hans/ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
