-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: add support for describe statement #125
Conversation
Adds support for DescribeStatement by transforming sql statements into a select statement that queries the (types of) the parameters in the original query. This can be used to temporarily support prepared statements until a DescribeStatement endpoint is available in the backend.
Codecov Report
@@ Coverage Diff @@
## postgresql-dialect #125 +/- ##
========================================================
+ Coverage 76.64% 77.51% +0.87%
- Complexity 866 953 +87
========================================================
Files 84 85 +1
Lines 3027 3260 +233
Branches 320 380 +60
========================================================
+ Hits 2320 2527 +207
- Misses 570 579 +9
- Partials 137 154 +17
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
if (parser.eat("select")) { | ||
// This is an `insert into <table> [(...)] select ...` statement. Then we can just use the | ||
// select statement as the result. | ||
return Statement.of( |
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.
Can we make the Select statement method reusable?
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.
Done
} | ||
} | ||
|
||
private Statement transformSelectToSelectParams(Set<String> parameters) { |
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.
Can we add examples as comment? Same for other parsers
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.
Done
} | ||
|
||
@VisibleForTesting | ||
Statement transformToSelectParams(Set<String> parameters) { |
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.
Can this be made more simple by just fetching columns name and the respective table name? Because from what I understand the resultant query can be made from just those?
If yes, we can use regex to fetch the respective values. Which will be more readable and be less error prone.
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.
No, that is not possible, as the type of a parameter might be different from the type of the column that it is used to for example filter. Consider for example the following statement:
select *
from my_table
where created_at > to_timestamp($1, 'YYYY-MM-DD HH:MI')
The type of the column created_at
is TIMESTAMP
, but the type of the parameter is text
.
Spangres does not (yet) support offset clauses that are not an integer literal.
…orm/pgadapter into test-describe-statement
Adds support for DescribeStatement by transforming sql statements into a select statement that queries the (types of) the parameters in the original query. This can be used to temporarily support prepared statements until a DescribeStatement endpoint is available in the backend.
With this change the entire extended query protocol is supported by PGAdapter.