Thread: extract vs date_part

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/

> (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