Skip to content
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

Add GETDATE, NOW as alias to parser + allow CURRENT_TIMESTAMP with parenthesis #1979

Open
paulrutter opened this issue Oct 4, 2024 · 4 comments

Comments

@paulrutter
Copy link
Contributor

paulrutter commented Oct 4, 2024

We're in the process of using the AlaSQL parser to validate query syntax in our product.
The AlaSQL parser currently does not recognize the following aliases to CURRENT_TIMESTAMP (see 61date.js).

  • NOW
  • GETDATE

Also, CURRENT_TIMESTAMP is recognized by the parser, while CURRENT_TIMESTAMP() is not.
Do note that all of these functions do work in a query, the parser just cannot properly validate their use.

I'm going to supply a PR to get this fixed, which has one drawback: now, current_timestamp and getdate can no longer be used as column aliases, as they're now reserved keywords.

Let me know what you think @mathiasrw.

@paulrutter
Copy link
Contributor Author

paulrutter commented Oct 4, 2024

Ps. The same applies to other date functions like DAY() and YEAR(), but that would break far more queries (although it would be more consistent). I tried that locally a while ago. See #1937 (comment)

With the proposed PR, at least all functions for getting the current date (+time) are consistently handled.

@mathiasrw
Copy link
Member

Thanks so much for contributing! I'll merge this when we're ready to bump the major version. Since we're currently restructuring the code to be ES6-friendly, it might take a few months before we can release breaking changes.

@mathiasrw
Copy link
Member

Is this a duplicate of #1981?

@paulrutter
Copy link
Contributor Author

paulrutter commented Dec 10, 2024

Is this a duplicate of #1981?

No, that seems entirely unrelated. Did you mean #1982?

#1982 indeed builds on this PR.
We could close #1980 and just go for #1982 instead, as it adds far more date functions to the parser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants