[PD] [psql] object hand-holding
hans at eds.org
Sat Dec 8 23:58:28 CET 2007
I'm not a big fan of [expr]'s syntax since it is custom syntax that
is not used anywhere else in Pd. Instead, you could achieve the same
result by using the interface I described, then embedded your SQL
statements with [sql] into a subpatch or an abstraction. This just
about any regular Pd user knows how to do.
On Dec 8, 2007, at 12:51 AM, Mathieu Bouchard wrote:
> On Fri, 7 Dec 2007, Hans-Christoph Steiner wrote:
>> That is done by sending the [submit( message to the hot inlet. Or
>> do you mean having multiple SQL calls separated by semi-colons?
>> If you wanted to add semicolons, there would have to be a special
>> message, I think we could just reuse the "addsemi", "addcomma",
>> "adddollar" messages from message boxes.
> The only SQL interface I'd really be happy to use (if I had to use
> SQL) is something using placeholders, sort of like [expr], but
> perhaps written in the usual SQL style:
> [sql select * from candies where flavour=? and colour=?]
> you wouldn't modify the statement any more than you modify an
> [expr] at runtime. this allows the statement to be precompiled by
> the server. you could still allow runtime change but perhaps it
> would get messy with multiple inlets, so let's assume for now that
> it is not supported.
> in the above example, [sql] has two inlets, one for each question-
> mark. Sending a list in the hot inlet is also correct, and "set"
> and "bang" do as usual. Each value will be quoted automatically,
> with appropriate apostrophes and backslashes and stuff, so that the
> user never has to do it. (my biggest problem with PHP is the lack
> of this feature).
> an alternate way to do it is to use the same syntax as [expr]. This
> allows a repeated value to not have to be repeated in the input to
> the object. However, this means that values are going to be typed,
> which is a bad match with SQL, which doesn't type values (it only
> types table cells themselves and casts everything automatically).
>> As far as I know, the semi-colon at the end of the statement in
>> SQL triggers the execution of that statement
> With this interface, there would be no semicolon at the end (or it
> would be optional and useless). The execution is done each time the
> hot inlet is activated (bang, float, symbol or list, but not others
> like set and whatever else if there's anything else).
>> so I can't see an advantage to having multiple, semi-colon
>> terminated statements in a single message box. Does it change how
>> the SQL is executed if they are submitted at the same time?
> Multiple statements are compiled as one function to which you pass
> all arguments you want at once. This could be useful if you want to
> do both insert and select in one go. It may be a bit faster, or
> maybe not, but it's convenient.
> [expr] supports semicolons and uses them for multiple outputs. For
> [sql], it might make only sense to have one outlet per query rather
> than by statement: that is, only SELECT and EXPLAIN and such would
> get an outlet, while INSERT and DELETE wouldn't, for example.
> At this point, I can't think of a case where I'd like to modify a
> SQL statement at runtime. Somehow it's possible to find a use, but
> I think that for almost everything you don't.
> _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
More information about the Pd-list