[christiangda]

What a dialect is was a section of the configuration guide. It now has its own page, docs/dialects.md.

The page

• Why a filter parser needs a dialect. The parser checks an expression and does not translate it, so "accepted" has to mean "the database runs it". What a disagreement costs: at best a database error on a request the parser called valid, at worst one text read as two different predicates.
• Choosing a dialect, with a decision diagram.
• How a filter is checked against it, with a diagram: the operator, then its spelling, then the allow-list, every problem joined.
• The dialect and the allow-list as two narrowings, with a diagram, and Dialect.Operators().
• Every construct the filter parser knows, in PostgreSQL 18 and in SQL:2023, with the standard's feature IDs, and PostgreSQL's manual's own words for each ❌.
• What each refusal says, word for word.
• What a dialect does not do:
  • it does not translate;
  • it does not know your column types or collation;
  • it does not change a pattern's meaning: without ESCAPE, the backslash is PostgreSQL's escape character and the standard has none;
  • it does not apply to sorting or field selection.
• What adding a dialect takes, with MySQL 8.4 as the next one: the operators it lacks and adds, its backslash escapes in strings, and tests against a running MySQL 8.4.

Also

• Every page that pointed at the old configuration section now points at the new page: README.md, getting-started.md, filtering.md, error-handling.md, migration.md, the documentation index's guide table, and the package doc. configuration.md keeps a summary.
• TestTheDialectsPageQuotesTheParser reads the page's table of refusals and holds each message to what Parse answers. A message changed on the page alone fails it; that was tested.
• The page's three diagrams were rendered, and so were the configuration guide's and the index's.

This goes into v1.1.1 with #29, which is tagged after this merges.

🤖 Generated with Claude Code