Why is DESCRIPTION colored as if it were a reserved word in Interactive SQL

[former_SQLA_member1694900]

Hi,

I thought DESCRIPTION is a reserved word. That would explain why it is colored in Interactive SQL to indicate that it is a keyword.

However, it looks that it is not a reserved keyword because the following only returns 'desc': select * from sa_reserved_words() where reserved_word like '%desc%'

So why do you think this is?

(Using SQL Anywhere 17)

[Breck_Carter]

FWIW description has never been a reserved word, where "never" includes V5.

ISQL 10 (for example) also color highlights description in blue, just like ISQL 17.

In other words, "blue" is meaningless, always has been, like "carrots will help you see in the dark" 🙂

[johnsmirnios]

"desc" is reserved but "description" is what we call a "keyword/identifier". That is, "description" could be used as an identifier in some contexts and as a keyword (ie, reserved word that is part of SQL syntax) in other contexts. Wherever possible, we don't create new truly reserved words because we don't want to break any existing SQL statements, stored procedures, etc by reserving a word that someone might already be using as a variable name, table name, column name, etc. sa_reserved_words() only returns strings that can never be used as identifiers and are always reserved.

[Breck_Carter]

In what context(s) is description "used as ... a keyword (ie, reserved word that is part of SQL syntax) in other contexts"?

I suspect the answer is "none, ever".

[johnsmirnios]

Well, "description" in particular is used in the context of a dialect that isn't exposed. However, there are many other "keyword identifiers": load, unload, datatype, quote, quotes, escape, publish, publisher, ... There are almost 600 of them.

[Breck_Carter]

OK then... if one accepts the usefulness of color highlighting (I don't), the highlighting of these words is justified because in most cases the words load, unload, etcetera, will be used as keywords rather than identifiers.

Having said that... if ISQL can't parse SQL (apparently it can't) then it shouldn't pretend that it can... computers aren't supposed to make mistakes, not even some of the time, so when ISQL gets the highlighting wrong it loses credibility.

[johnsmirnios]

ISQL is probably getting the list of tokens from the same place as the database server... and although "DESCRIPTION" is not in a dialect that happens to be exposed, it is in the list of tokens.

[johnsmirnios]

Actually, out of curiosity I dug a bit deeper. A long time ago (1999), one could create event 'types' along with a description for a scheduled event though I don't know if we ever shipped that. It might have been a work in progress.

create_event_type: T_CREATE event_type

event_type: T_EVENT T_TYPE identifier T_DESCRIPTION T_STRING

So there was a statement of the form

CREATE EVENT TYPE foo DESCRIPTION 'do stuff'

The ability to manage a distinct set of event types (probably in a system table) and have associated descriptions seems to have been removed and the event type is specified when you create the event (sans description).