You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR here is somewhat a beginning of a conversation about how do we
want to make proper sql identifiers when it comes to schemas, tables and
columns, particularly for my use case I want this in order to use sql
reserved words for table names. I'll try to split this into 2 logical
parts:
**How do we know how to escape depending on db variant?**
A SQL 1999 rfc says that double quotes should be used in order to escape
an identifier, nevertheless:
- in mysql it is backticks
- in h2 when you escape you suddenly loose the ability to refer to a
table ignoring it's definition case: defining a table `T`, `SELECT *
from t` will work, `SELECT * from "t"` will not
Therefore it felt logical to make an escaping mechanism based on
`Dialect`. I didn't want to propagate `DialectConfig` together with
`Context` down the call chain, it seemed to me kinda redundant, so I
made `DialectConfig` part of `Context`. That's how we can access
escaping mechanism in various places as long as you have `Context`
**How do we decide which table to escape?**
With this PR I want to stick with tables, otherwise it can become too
big. I see three options:
1. escape all tables
2. escape based on list of reserved words per database variant
3. let user decide to escape
First options we already discarded as one that will change too much
tests. As for a second option - I looked into lists of reserved words,
and they are very different based on database, also it will not be fun
to maintain them, that's why most of the libs resolve to escape all
tables. Third option is most simple for now, since it will allow users
to opt-in when they want/bump into this issue, also it will allow us to
test mechanism first without changing all 1k+ tests, and perhaps we can
start with option 3 and then eventually move to option 1. Therefore in
this draft PR I made a flag in `Table` to opt in for escaping table
name.
_Optional_:
At the moment `DialectConfig` is kinda part of the `Dialect`, and I
don't feel entirely good about including whole `Dialect` in `Context`. I
kinda want to move `DialectConfig` into case class and make a separate
implicit for it as a part of `Dialect` so that when we need to construct
`Context` only `DialectConfig` case class will be picked up
It is a draft PR yet, so obviously I haven't written tests for all
cases, only for a simple `FROM` expression. This will follow when we
come to consensus about the implementation.
What do you guys think?
fixes#53
0 commit comments