On Dec 10, 2007, at 2:07 PM, Mike McGonagle wrote:
---------- Forwarded message ---------- From: Mike McGonagle mjmogo@gmail.com Date: Dec 10, 2007 1:07 PM Subject: Re: [PD] [psql] object hand-holding To: jamie@postlude.co.uk
On 12/10/07, Jamie Bullock jamie@postlude.co.uk wrote: 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.
One of the things that I have been reading on this is that when you
use these 'pre-complied' SQL statements, you need to 'bind' each of
the variables with their types to a specific function. (Also, I
kind of like the ':' syntax, as it puts a name to the data within
the statement.) I also think that we would need to do something like[insert into table (id, name) values (:id, :name) ( <-- sent to the
cold inlet [bind :id float( <-- sent to hold inlet [bind :name symbol( <-- sent to hold inlet[:id 1 ( <-- sent to hold inlet [:name john ( <-- sent to hold inlet [bang ( <-- sent to hold inlet
and then we would be able to put all the data into the database
with the expected types. At least SQLite and libdbi use these
'bind' functions to associate the expected datatype with the input
data.
(What is the "hold" inlet, by the way?)
It would be really nice to be able to have inlets for the sql
placeholders, but I couldn't think of a clean way to do it. We could
try the dynamic allocation like you say here, I don't know if I have
a specific objection to it, but it could get weird. Since the SQL
inlet has to be cold to support the comma hack, then these dynamic
inlets shouldn't be hot since they are the right of a cold inlet.
But that's not a big deal.
Also, I don't know if any objects do this kind of dynamic inlet
creation after the object itself has been instantiated. It might not
even be possible. I figure that you can easily make a subpatch or
abstraction around the SQL message generation, then manage the inlets
there. Perhaps not ideal, but it's not difficult to do and follows
existing practice.
As for the SQL binding, I was thinking it would happen inside of the
object, binding the placeholder names to the selectors. As long as
there wasn't any new input on the SQL inlet, then the SQL statement
wouldn't need to be recompiled.
Another question I just thought of it how to handle returning
multiple results from s single query. If it followed the [textfile]
style, then you would have to bang to get each individual result,
then keep banging until you get a bang on the status/second outlet,
meaning the query was done. I think this could work.
.hc
There is no way to peace, peace is the way. -A.J. Muste