-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sqlparser: support expression type hint #482
Conversation
336aaf6
to
df96076
Compare
parse/sql/tree/sql-writer/writer.go
Outdated
@@ -38,6 +44,11 @@ func (s *SqlWriter) String() string { | |||
s.stmt.WriteString(")") | |||
} | |||
|
|||
if s.typeHint != "" { | |||
s.stmt.WriteString("::") | |||
s.stmt.WriteString(s.typeHint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work, because our types aren't named the same as Postgres's. Also, I don't think the writer
package is the right place to do this. It seems like it should individually be written in each expression's ToSQL()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the writer package is the right place to do this
Yeah you're right, since only expression has typeHint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because our types aren't named the same as Postgres's
For now I have no checks on typeHint
, so you can pass Postgres's type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, shouldn't we expect Kwil schema types and translate them to PG types when writing the statement out from the AST (or when generating the AST from the user code)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, but we only have int and string, which is pretty constraining...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we need a supported type list, then translate it when ToSQL
.
I think it's time to extend our supported column types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. Safest may be to use just the two Kwil types, and then we map those to either TEXT or INT8 in the type cast.
Seems to me that the main purpose of this (at present anyway) is to allow the author to assert type to disambiguate between integer or string, also to reinterpret type as needed for downstream instructions within an action. Maybe we add the different integer types later, with boolean and possibly our own 32-byte integer type when we are ready and have thought through the implications.
df96076
to
39af5b0
Compare
39af5b0
to
5c3b092
Compare
@@ -93,7 +93,7 @@ require ( | |||
github.com/jmhodges/levigo v1.0.0 // indirect | |||
github.com/klauspost/compress v1.17.0 // indirect | |||
github.com/kwilteam/action-grammar-go v0.0.1-0.20230926160920-472768e1186c // indirect | |||
github.com/kwilteam/sql-grammar-go v0.0.3-0.20230925230724-00685e1bac32 // indirect | |||
github.com/kwilteam/sql-grammar-go v0.0.3-0.20240202213606-3f118696cec5 // indirect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since 3f118696cec5
isn't on main
of that repo, we should get kwilteam/sql-grammar#3 and then kwilteam/sql-grammar-go#3 before this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, theses refs will break when those PRs merge and the feature branches are deleted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, are you on this?
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
* sqlparser: support expression type hint * handle typeHint only in Expression * rename to TypeCast, with predifiend types
Support type hint in sql expression, so that could be used to cast/infer type of an expression.
Description
Related Issue
Following prs should be merged first, then update go.mod accordingly.
Motivation and Context
How Has This Been Tested?
Types of changes
Checklist:
Checklist Explanation:
How to Review this PR:
sql syntax changes are in kwilteam/sql-grammar#3
changes made to sqlparser are mostly just set
TypeHint
to certaintree.ExpressionXX
Additional Information:
'type hint' works as below:
This logic is also enforced in the sqlparser.
TODO:
TypeHint
type?TypeHint
value