From: John Cowan <xxxxxx@ccil.org>
Date: Thursday, October 24, 2019 7:21 PM
On Sun, Oct 20, 2019 at 9:10 AM <xxxxxx@ancell-ent.com> wrote:
(create-table-if-not-exists items
  (#(itemid varchar-not-null))
and
(CREATE-TABLE-IF-NOT-EXISTS items
  (#(itemid VARCHAR-NOT-NULL))
I've modified it so that symbols with hyphens are split up but not further processed, so they have to be runs of keywords (which is what I intended).

However, there remains a problem I can't do anything about. SQL converts unquoted names to upper case, so CREATE TABLE foo; and CREATE TABLE foo; both create a table named FOO.

The standard says so, but PostgreSQL case folds "unquoted names" to lower case, explicitly in violation of it: https://www.postgresql.org/docs/current/sql-syntax-lexical.html

If you actually want a table actually named foo, you can do it in SQL with CREATE TABLE "foo", because SQL double quotes are like Scheme vertical bars, but my notation doesn't give you any way to make that happen. I thought of having an ad hoc rule like $foo -> "foo", but then what if you want the identifier "$foo"? It's not clear to me whether that's a valid SQL identifier or not.

It would be more clear, and I think more elegant, to use the same character at either end, for example $foo$.

But which character to use is messy. Per the 2011 SQL standard, page 158 of my copy of a draft:

Syntax Rules:

1) An <identifier start> is any character in the Unicode General Category classes “Lu”, “Ll”, “Lt”, “Lm”, “Lo”, or “Nl”.

NOTE 95 — The Unicode General Category classes “Lu”, “Ll”, “Lt”, “Lm”, “Lo”, and “Nl” are assigned to Unicode characters that are, respectively, upper-case letters, lower-case letters, title-case letters, modifier letters, other letters, and letter numbers.

(So in theory an identifier could start with U+12466 CUNEIFORM NUMERIC SIGN ELAMITE TWO THIRDS 𒑦....)

But going back to PostgreSQL, per the above link it also allows starting with underscore (_), and allows $ after the start, which it says is not allowed in the standard.

The simplest way to solve this would be to pick a default character that's not allowed by the SQL standard, and most or all the databases we know of, or the FOSS three that get "first class" support, and allow the user to change it. Perhaps allow changing it between S-expressions.

[...]

- Harold