[Introspection] Support non-alphanumeric characters in field names

[janpio]

• error: Unexpected token. Expected one of: field type.
• format-of-id-on-relation
• @id field is model (which is not supported)

and

• error: Unexpected token. Expected one of: End of block ("}"), field declaration.
• unexpected-token-field-starts-with-number
• Field name starts with number

---

Currently non-alphanumeric characters cause errors:

#1078
#1079
#1080
#1081
#1082
#1106
#1076 (also covers model names)

We need a way to support non-alphanumeric characters in these field/column names.

Investigation and decisions at #1106 (comment)

---

User issues that report these problems:
#1067
#1093

[janpio]

Copy paste of decision from @sorenbs:

Column names / field names

Background

In SQL, an identifier can be quoted. This generally mean that it is wrapped in a start and closing character. For Postgres this character is ". We always use quoted identifiers as this has no downsides and allow us to support the widest range of identifier names.

MySQL

Extended: U+0080 .. U+FFFF

dev.mysql.com/doc/refman/8.0/en/identifiers.html

Postgres

Quoted identifiers can contain any character, except the character with code zero. (To include a double quote, write two double quotes.) This allows constructing table or column names that would otherwise not be possible, such as ones containing spaces or ampersands. The length limitation still applies.

postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

SQLite

No constraints

stackoverflow.com/questions/23770480/sqlite-table-and-column-name-requirements

MongoDB

Field names cannot contain the null character.
Top-level field names cannot start with the dollar sign ($) character.

docs.mongodb.com/manual/reference/limits/#Restrictions-on-Field-Names

Decision

We will support the full space of names for each supported database.
To that end, we will always use the quoted representation of an identifier.
Further, we will introduce the concept of a quoted identifier in the Prisma schema. We will only use the quoted form when needed, as it is ugly. See note below.

Note on the serialised Prisma Schema and spaces

Column and table names may contain spaces. We need to decide how we want to handle this in the Prisma Schema.

For example, a Integer column named age String would result in a schema like this:

model User {
  age String Int
}

To overcome this, we will introduce quoted identifiers:

model User {
  "age String" Int
}

The use of double quote is in line with the official SQL standard, but the resemblance is of no importance, as we also support non-SQL databases.

Temporary Guardrail

For now we will simply replace any invalid character with _ and add a @map() attribute

So:

model User {
  age String Int
}

Become

model User {
  age_String Int @map("age String")
}

[janpio]

Addendum to Guardrail:

1:

non alphanumeric characters (e.g. _) at the beginning of the string are removed:

model User {
  _age Int
}

becomes:

model User {
  age Int @map("_age")
}

2:
If renamed column clashes with existing column, error out.

cc @sorenbs 👍 pls if agree