[PD] Fwd: [psql] object hand-holding

Hans-Christoph Steiner hans at eds.org
Mon Dec 10 21:29:47 CET 2007

On Dec 10, 2007, at 2:07 PM, Mike McGonagle wrote:

> ---------- Forwarded message ----------
> From: Mike McGonagle <mjmogo at gmail.com>
> Date: Dec 10, 2007 1:07 PM
> Subject: Re: [PD] [psql] object hand-holding
> To: jamie at postlude.co.uk
> On 12/10/07, Jamie Bullock <jamie at 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.



There is no way to peace, peace is the way.       -A.J. Muste

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071210/6225e7df/attachment.htm>

More information about the Pd-list mailing list