Support EXTRACT function-like operator

[benesch]

The EXTRACT function, for extracting components of a date from a
timestamp, has special syntax: EXTRACT(<field> FROM <timestamp>).

[coveralls]

Pull Request Test Coverage Report for Build 280

• 54 of 57 (94.74%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.05%) to 91.39%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tests/sqlparser_common.rs	19	20	95.0%
src/sqlparser.rs	20	22	90.91%

Totals
Change from base Build 279:	0.05%
Covered Lines:	3662
Relevant Lines:	4007

---

💛 - Coveralls

[nickolay]

I'd prefer field: SQLDateTimeField to be a String instead of a custom enum, as everyone has their own idea of what values are allowed here:

• ANSI defines TIMEZONE_HOUR | TIMEZONE_MINUTE in addition to the ones you have implemented,
• Oracle additionally has TIMEZONE_ABBR and TIMEZONE_REGION,
• and MySQL wins the contest with a dozen of additional supported fields...
• (edit: I'd say they share the first place with Postgres actually)

Alternatively, I'd be happy to hear any suggestions on how to deal with future PRs wanting those extensions to be supported - just add everything to the enum?

[nickolay]

Given that #99 depends on this, I'm fine with merging this "as is", as long as we agree on the future direction.

[benesch]

Given that #99 depends on this, I'm fine with merging this "as is", as long as we agree on the future direction.

Ok, great, I'm going to go ahead and merge, as I'm definitely OK with SQLDateTimeField evolving to a string in the future.

Alternatively, I'd be happy to hear any suggestions on how to deal with future PRs wanting those extensions to be supported - just add everything to the enum?

Yeah, I don't see anything particularly appealing here. All of the options I can think of have some serious cons:

• Use conditional compilation to add enum variants based on feature flags. This is appealing because users would get all the usual compiler support around exhaustive matching of enums, and wouldn't see anything irrelevant to their dialect. But we'd seriously break the existing API, because users would have to choose, at compile time, what dialect to support. And perhaps there are users who depend on being able to parse multiple dialects?

• Write dialect-specific ASTs (that are largely copies of the general AST, but omitting irrelevant fields and enum variants), and then write transformations that lower the general AST to the dialect-specific ASTs. This would be a colossal amount of work for any change that affected multiple dialects (i.e., most dialects).

• Make the enum generic over Dialect, and add a DialectSpecific(_) variant. I think @andygrove suggested this somewhere. This is a bit ugly, but maybe a nice balance between maintainability and user convenience.