Date: Friday, October 25, 2019 11:39 AM
How about a vector whose sole member is a string [ for inserting raw text as an escape mechanism ]? I'm kludging here, but I've also run out of types with printable representations.
[ rest of message below ]
Yeah, that sounds fairly good. It ups the number of things vectors do to three, which I consider to be a human factors maximum, and doesn't look like either of the two other uses.
Do you mean #("string") or #(string)? I think either works, strictly speaking, but the former is much clearer in intent, and results in a simple dispatch rule: is the contents a list (and only a list), a string (and only a string), or neither?
BTW, the "(create-table-if-not-exists items..." example looks like it has way too many closing parens.
Hmmm, sorry to say, but looking really really closely at that CREATE TABLE example, I think it fails the goal of "without knowing much about SQL", although there's value to moving from the domain of strings to S-expressions. It does not look to me like you can use it without knowing the SQL it's going to be transformed into, i.e. "why a list vs. why a vector *here*??". Or you'll have to learn a different set of mostly ad hoc rules, while still needing to know raw SQL for many reasons.
Using the simple example:
SELECT foo.a, bar.a
FROM foo, bar
WHERE foo.b = bar.b;
created by:
(select #((foo.a bar.a))
from #(foo bar)
where (:= foo.b bar.b))
Why would I know to use a list inside a vector after the select, leave "from" bare, then use a vector for "foo bar" -> "foo, bar", again leave "where" bare? The list that follows is intuitive, prefix notation for operators is definitely cool. The CREATE TABLE DDL is a lot better, but DDL is a rather different beast, generally done at a different time than when you do your operations.
If writing by hand, I'd personally stick to writing a real SQL statement than use this. But syntax more complicated than e.g. Lisps, SQL, and say C as an upper bounds are not my forte, you need to get some other opinions. For now, I'm treating this as a further sobering lesson that DSLs for SQL are hard.
- Harold
----- Original message -----
[ see above ]
Date: Friday, October 25, 2019 10:06 AM
Feh. SQLite, it turns out, supports quoted identifiers only in column aliases.
It's "Industrial Strength" in its own ways.... And that's very possibly an 80/20 or nearly so for quoting identifiers.
That page pointed out something else, namely that it's valid to say:
SELECT "SELECT", "select" from "Select" ...
But I say it's spinach,
And if I remember correctly the PostgreSQL documentation I just reviewed says it will error on that. Except it might take Select, I think it said it would do the obvious but non-standard thing for mixed case identifiers.
and I say the hell with it.
That's probably OK, although those of you who've seen lots of databases in the wild, have you seen much of this? Were any of those databases you really want to work on ^_^?
I'm already covering far more than 80:20 here. I'm not even going to bother with dollar signs. I'll stick with the change I already made, because we don't want people writing create-table-foo anyway, but capitalizing keywords is for SQL (a case-insensitive language however you look at it), not for its S-expression image in a case-sensitive language.
Yeah, create-table-foo is very bad form and in no way required, while surely there are are some databases out there with wild schema. But as you note, you're almost certainly way beyond 80/20 now.
Although, what about a general escape? I.e. a mechanism for "insert exactly this text *here*"?
- Harold