On Dec 7, 2007, at 8:44 PM, Mike McGonagle wrote:
On 12/7/07, Hans-Christoph Steiner <hans@eds.org> wrote: This would allow for the comma trick, etc. and I think it would fit better into Pd's message processing. In addition, there could be a single line message for the hot inlet, like this:
Hans, I was thinking a little bit more about this, and I think I see what you are getting at, I will have to try to mock this up at home tonight. The only trouble that I can still see here is how to indicate that an SQL statement is complete.
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.
As far as I know, the semi-colon at the end of the statement in SQL triggers the execution of that statement, 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?
The other thing I think that would have to be is forcing all input SQL to go into the second inlet. Allowing some things to go into the hot inlet, while others are required to go into the second outlet would make it difficult to use because you would have to remember which type of statement can go where...
Any SQL statement would be allowed on the cold inlet. Because of the limitations of Pd (no escape mechanism), and the fact that commas already have a meaning in Pd messages, the hot inlet would not be able to handle commas (unless someone comes up with something quite clever).
One advantage of having the second, cold inlet is that it could be devoted to SQL statements, so you don't need to start each message with "sql" and there wouldn't be any words that the [sqlite] object used, like "open", "close", etc. Having the comma handling on the second/cold inlet only means that the first/hot inlet also doesn't need the preceeding "sql" selector since SQL statements will only start with a small set of selectors (CREATE, DROP, INSERT, SELECT, etc).
For clarity, I added another cold inlet example and a sketch of building a big query. The big query example in the psql help points out something that I think could get quite confusing, separating the chunks with "sqlend, sql".