[PD] [psql] object hand-holding

[Hans-Christoph Steiner]

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_______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

                                               http://at.or.at/hans/