Should ABS trigger Q442?

[Alessandro Gatti]

Hi there,

I'm wondering why ABS is in the abbreviated keywords list, as (to the best of my knowledge) it is not really an abbreviation but a proper function. I'm using PostgreSQL but from what I've seen both SQL Server and MySQL do have that function (PostgreSQL also has an abbreviated form of that function, @ <number>, but that's even worse...).

Are there any plans to remove that from such list or should I stick with # noqa: Q442?

Thanks!

[Phil Jones]

I think you are correct, in that I can't find evidence a absolute function exists. Would you like to propose a PR?

[Alessandro Gatti]

EDIT: Nevermind, CREATE statements aren't parsed it seems.

---

I'm actually working on it. However if ABS gets removed from the abbreviations then the whole abbreviated_keywords.py test case goes away. I've added something to keep the functionality being tested and turns out that it might be bugged.

If I read things right, CREATE TABLE tbl (clmn DEC) doesn't trigger a warning even though DEC is an abbreviation and is present in the known abbreviations list. I put this in the test case:

query = "CREATE TABLE tbl (clmn DEC)"  # Q442
query = "CREATE TABLE tbl (clmn DECIMAL)"

and the test fails with

E       AssertionError: assert set() == {(1, 'Q442')}
E         Extra items in the right set:
E         (1, 'Q442')

which I assume it means Q442 was not triggered. Is that so?

[Alessandro Gatti]

Now that I think of it, should DEC and CHAR be in that list as well? Unless I'm missing something, they can only be used in CREATE statements, which are currently not parsed.

Maybe PROC too? If it's an abbreviation for PROCEDURE then the same remark as above applies, I think. (Caveat: I'm most familiar with PostgreSQL and SQLite, not sure whether other SQL databases use those keywords in another context)

[Phil Jones]

I'm not that certain either, but I'm happy to merge a PR that adds them.