Quote from Darren Duncan on April 25, 2025, 3:36 am

Quote from dandl on April 25, 2025, 1:44 am

So the aim is (or might be) to allow the database designer total freedom in the choice of table names, column names, etc. The designer can choose select * from payroll where id  like '%"%' as the name of the table produced by that query. So then the language needs a way to denote arbitrary strings of characters as identifiers, just to keep the parser happy.

Trivial. The result is a single token, marked out by start and end sequences. The only minor challenge is devising an end sequence in a way that it cannot appear inside the token. Here's one way to do it. If you don't like this one, I've got plenty more.

• "John O'Dwyer"
• @"John O'Dwyer"
• @/"John O'Dwyer"/
• @#/"John O'Dwyer/"#
• @\v~!@#$%^&*()_+John O'Dwyer-={}[]:";',./<>?\v

I have 2 responses to this:

1. As I said previously, just reuse the existing delimiters and escape sequences we already have for regular string literals; there is no need to invent more like in your examples, or have any of the added complexity. Most application programming languages with quoted identifiers do this very thing already, I believe, reuse their String type or whatever its called for identifiers.

2. That said, regarding your concern about the delimiter not appearing between the delimiters, I happened to make a design decision for my Muldis stuff to have all escape sequences not include the character they are a sequence for, and also I have an escape sequence for quotation marks, so my string literals never include the literal delimiter, and it is in fact illegal. So for example, the escape sequence for the quotation mark and backslash are respectively \q and \k respectively (I avoided using the letters with established meanings for these things, eg \n means what it normally means). I made this choice, rather than say using \" so that the parsing is much simpler. Also I only have a single quoted character string literal that doubles for use with identifiers.