Allow keywords as function names in dialects

[agentm]

In PostgreSQL and BigQuery, it's common to see data types being used as type constructors looking like functions:

In PostgreSQL:

SELECT DATE('2000-01-01');
SELECT TIME('5:00:00'); --this fails to parse
SELECT TIMESTAMP('2000-01-01'); --this fails to parse

In BigQuery:

SELECT DATE('2000-01-01');
SELECT TIME('5:00:00'); --Could not cast literal "5:00:00" to type TIMESTAMP at [1:13]- ???
SELECT TIMESTAMP('2000-01-01'); --works fine

The other variants are CAST(blah AS DATE), date '2001-01-01', or '2001-01-01'::DATE.

Obviously, there is some buggy and inconsistent behavior in the backends, but would it be possible to simply parse these as dialect-specific App functions?

I assume it would be merely a matter of disabling the blacklist when scanning for an App. Does that sound reasonable or is there a footgun lurking here?

[JakeWheat]

I think this is the solution: https://github.com/JakeWheat/simple-sql-parser/issues/8 This has a whitelist which overrides the blacklist on specific names in the App parser only. If this is needed for other bits of syntax, then something similar should be done.

I think SQL syntax is a mess in this regard (and many others). I think this blacklist/whitelist approach addresses the mess exactly at least.

[JakeWheat]

Regarding CAST(blah AS DATE), date '2001-01-01', or '2001-01-01'::DATE, in case there is ambiguity, I think these should parse to a cast, to a special syntax (this is a literal only, not a general cast from any expression), and to a cast respectively. I prefer to try to avoid making it parse straight to too much an abstract tree, more like a lightweight parse tree if that makes sense. This is more beneficial in SQL than some other syntaxes because SQL syntax is so convoluted. It helps with pretty printing, and other subtler things when working with the syntax. I'm not 100% happy with CAST(blah AS DATE) and '2001-01-01'::DATE parsing to the same thing.

[JakeWheat]

I'm still not sure if removing these from the keyword list so that they parse, or adding them to the function whitelist so they only parse as Apps and not e.g. as an identifier, will cause problems. But doing either is easy to try out. The lastest push to master has the ability to remove keywords from the keyword list easily, so you could try it out and see how it works. I'm not against also making it possible to change the App whitelist from the dialect too, if this is useful. Example: use this dialect with the parser:

ansi2011 {diKeywords = filter (/="date") (diKeywords ansi2011)}

and now

SELECT DATE('2000-01-01');

will parse.