ISTM that it is mighty confusing that extract() and date_part() don't
accept the same set of "field" arguments.

-> SELECT EXTRACT(decade FROM TIMESTAMP '2001-02-16 20:38:40');
ERROR:  parser: parse error at or near "decade"
=> SELECT EXTRACT("decade" FROM TIMESTAMP '2001-02-16 20:38:40');
ERROR:  parser: parse error at or near """
=> SELECT date_part('decade', TIMESTAMP '2001-02-16 20:38:40');
 date_part
-----------
       200

This can be an easy grammar fix:

diff -c -r2.220 gram.y
*** gram.y      2001/02/09 03:26:28     2.220
--- gram.y      2001/02/16 19:42:42
***************
*** 4987,4992 ****
--- 4987,4993 ----
                ;

  extract_arg:  datetime                                                { $$ = $1; }
+               | IDENT                                                 { $$ = $1; }
                | TIMEZONE_HOUR                                         { $$ = "tz_hour"; }
                | TIMEZONE_MINUTE                                       { $$ = "tz_minute"; }
                ;

(Using ColId instead of datetime + IDENT gives reduce/reduce conflicts
that I don't want to mess with now.)

The date_part implementation is prepared for unknown field selectors, so
this should be all safe.  Comments?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Fri, 16 Feb 2001 20:56:43 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
extract vs date_part
> (Using ColId instead of datetime + IDENT gives reduce/reduce conflicts
> that I don't want to mess with now.)
> The date_part implementation is prepared for unknown field selectors, so
> this should be all safe.  Comments?

Works for me. Since extract required explicit reserved words, I had just
implemented the ones specified in the SQL9x standard. Your extension
patch is a great idea, as long as others agree it can go into the beta
(afaict this is an extremely low risk fix).

                      - Thomas

Fri, 16 Feb 2001 20:18:58 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: extract vs date_part