Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Wrap timestamps in ROWTIME expressions with STRINGTOTIMESTAMP #3160
Wrap timestamps in ROWTIME expressions with STRINGTOTIMESTAMP #3160
Changes from 3 commits
57fc729
de01aeb
3b4e214
579c691
7b1352a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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 might explicitly call out here that all unspecified elements of the full pattern are right-padded with zeros
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.
somewhere in here i would expect to see a mention of timezone handling too, as this always trips people up.... i.e. in what TZ are your iso-8601 strings interpreted ? that of teh running jvm or utc or ....?
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 will match any expression with
ROWTIME
in it. For instance, it will match the following expression where you should not indeed rewrite the expression:TIMESTAMPTOSTRING(ROWTIME, 'yyyy-MM-dd HH:mm:ss') = '2019-08-08 12:12:12'
.You need to change this such that it only rewrites the cases you have mentioned in the docs.
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 particular statement remained the same, but the rewriter itself has been updated to only rewrite timestrings when one side of the comparison is exactly
ROWTIME
.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.
Does this line do anything other than return a duplicate of the function call node? I think
StatementRewriter
should beabstract
as its meant as a base class for rewrites. In itself it doesn't actually change the query, right?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.
It stops the rewriter from further processing anything within a function. So, if the expression looks like
ROWTIME > FOO('2017-01-01 ' + 100) + '2019-01-01'
, then'2019-01-01'
will get wrapped but'2017-01-01'
doesn't. This actually also addresses the first point above, since function calls don't get rewritten at all.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.
Isn't this a bit dangerous? We're assuming FOO is returning a
long
and that represents a datetime, but this might not be the case, e.g.SELECT * FROM orders where IS_LEAP_YEAR(ROWTIME + 6000) > '2017-01-01 00:00:00.000' + 35;
wouldn't make sense!I don't think we can make any such assumption on the return value from a function.
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.
My thoughts were that this is purely a query rewriter, so those kinds of cases would get caught later on. So for example,
IS_LEAP_YEAR(ROWTIME + 6000) > 35
passes this step, but would still eventually get caught during evaluation. I did change the overall logic of the rewriter as per @hjafarpour's comment though.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.
They may get caught later on, but the UX for the user is not great. There's going to get some message that
Foo can not be compared to Long
or something, which is very confusing for the user.