Skip to content

Any non-keyword word is considered as identifier #189

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

Closed
vladshcherbin opened this issue Mar 7, 2024 · 6 comments
Closed

Any non-keyword word is considered as identifier #189

vladshcherbin opened this issue Mar 7, 2024 · 6 comments
Labels
no-stale Prevent making as stale

Comments

@vladshcherbin
Copy link
Contributor

Describe the bug

insert into "brands" ("name") values ('Aston Martin') returning "id", "name"

In this example returning keyword is not in keywords list and is considered as identifier.

Expected behavior
Any non-keyword should be considered unknown or all keywords should be added to the keywords list.

All keywords can be taken from postgres docs

Screenshots

image

sql-highlight (please complete the following information):

  • Version: 5.0.0-beta.2
@scriptcoded scriptcoded added the no-stale Prevent making as stale label Mar 10, 2024
@Qtax
Copy link
Contributor

Qtax commented Mar 12, 2024

This is also an issue for any non-postgres SQL dialect that has more/some other keywords.

@wkeese
Copy link
Contributor

wkeese commented Apr 6, 2024

Any non-keyword should be considered unknown

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.

@wkeese
Copy link
Contributor

wkeese commented 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
Copy link
Owner

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
Copy link

kodi commented Mar 18, 2025

Another question,

I am running into problems, with

insert into "schema"."tbl_name"...

where schema.tbl_name will be considered string instead of identifier.
you can see the same thing happening here with "brands"

@wkeese
Copy link
Contributor

wkeese commented 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:

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?

select * from "emp where "name" = "Bill"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-stale Prevent making as stale
Projects
None yet
Development

No branches or pull requests

5 participants