extract vs date_part

Started by Peter Eisentrautalmost 25 years ago2 messages
#1Peter Eisentraut
peter_e@gmx.net

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/

#2Thomas Lockhart
lockhart@alumni.caltech.edu
In reply to: Peter Eisentraut (#1)
Re: 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