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
{{ message }}
Repository navigation
Any non-keyword word is considered as identifier #189
If we did that though, then no strings would be marked as identifiers.
or all keywords should be added to the keywords list... All keywords can be taken from postgres docs
I guess that's a better argument, although I cringe to think that in a string like below, "a" and "c" would be marked as keywords rather than identifiers:
select * from tab where a > c
The current architecture (doing everything by regexp) has inherent limitations, so there need to be some compromises. It seems like adding all those strings as keywords might make things worse (overall) rather than better.
Hey there. I think to avoid the odd cases such as a > c we'll just keep accepting suggestions for new keywords for the time being. The returning keyword was added in #188 so I'll mark this as closed.
@kodi - I think that's just how it works; the whole architecture is based on regexps so there's no way to differentiate between the two strings in this example:
select * from "emp" where name = "Bill"
Actually I'm surprised you can quote schema or table names at all. Can you quote column names too? Given a command like below, how could a database know that "name" is a column but "Bill" is a literal string?
Activity
Qtax commentedon Mar 12, 2024
This is also an issue for any non-postgres SQL dialect that has more/some other keywords.
wkeese commentedon Apr 6, 2024
If we did that though, then no strings would be marked as identifiers.
I guess that's a better argument, although I cringe to think that in a string like below, "a" and "c" would be marked as keywords rather than identifiers:
The current architecture (doing everything by regexp) has inherent limitations, so there need to be some compromises. It seems like adding all those strings as keywords might make things worse (overall) rather than better.
wkeese commentedon Apr 6, 2024
PS: I guess what I'm saying is that it's only safe to list reserved keywords in the keywords section (and "returning" is non-reserved).
scriptcoded commentedon Jul 2, 2024
Hey there. I think to avoid the odd cases such as
a > cwe'll just keep accepting suggestions for new keywords for the time being. Thereturningkeyword was added in #188 so I'll mark this as closed.kodi commentedon Mar 18, 2025
Another question,
I am running into problems, with
where schema.tbl_name will be considered string instead of identifier.
you can see the same thing happening here with
"brands"wkeese commentedon Mar 20, 2025
@kodi - I think that's just how it works; the whole architecture is based on regexps so there's no way to differentiate between the two strings in this example:
Actually I'm surprised you can quote schema or table names at all. Can you quote column names too? Given a command like below, how could a database know that "name" is a column but "Bill" is a literal string?