Commented by: @livius2

I see one problem with this, a tabe structure and what it contain.
If it present only info about reserved words in currend FB version than it will be simple. But if it should show historical chanes it should have repeated all words for all FB versions as e.g some word is reserved in FB2.5 but it is not a reserved word in FB3.

Commented by: @dyemanov

I'd say this table should be virtual and enlist only keywords for the current engine version.

Commented by: @hvlad

> I'd say this table should be virtual

Does you consider to use RDB$TYPES ?

> and enlist only keywords for the current engine version.

and [non-]reserved status, please

Commented by: @AlexPeshkoff

Maxim, FYI - since interbase times we have API call:
int API_ROUTINE KEYWORD_stringIsAToken(const char* in_str)
which returns non-zero if in_str is reserved word.

Commented by: @asfernandes

Vlad,

v3 sub releases had a new keyword (LOCALTIME).

Use of RDB$TYPES may be problematic under this circumstance.

I prefer virtual table.

Commented by: @asfernandes

Alex, being a client API, it's certainly not good enough.

Commented by: @hvlad

Adriano,

I'm not insist on RDB$TYPES, just want to make sure we take this into account and make a smart decision.

Commented by: @hvlad

Alex,

API function doesn't get list of keywords from the actual engine, i.e. it depends on fbclient version and could be far from reality.

Commented by: @dyemanov

I consider RDB$TYPES (or any other persistent table) problematic. Imagine an ODS13.1 engine accessing an ODS13.0 database. RDB$ table will show keywords from the prior engine version, while the newer engine may support new keywords. This is why I have suggested a virtual table instead.

Commented by: @asfernandes

Pull request created: https://github.com/FirebirdSQL/firebird/pull/310/files