Re: Simplicity in time/date functions

So there you have it folks, I knew there was a logical explanation.
Thanks for clearing that up. And thanks for everything else that you
guys do as well.

I am also glad to know that my somewhat irrational feature of
CURRENT_DATE() was based at least somewhat in fact. I lurk on the
HACKERS list (mostly because it is so darn educational), but I never
can be sure if my prejudices have arisen from my own fevered
imagination or from something I read on the list. As far as I am
concerned, if one of the Core PostgreSQL hackers doesn't like a
particular grammar than it is more than enough reason for this mere
mortal to stay clear the heck away from it :). There's nothing worse
than having to edit SQL statements that have been working fine for 6
months just because you added a superfluous set of ()'s.

Thanks again,
Jason

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Jason Earl <jason(dot)earl(at)simplot(dot)com> writes:
> > Try:
> > processdata=> SELECT CURRENT_DATE - 28;
>
> > Thomas could probably explain why this is.
>
> Because the SQL92 spec says so.
>
> CURRENT_DATE with empty parens *is* allowed by ODBC, apparently, and
> for 7.2 Peter Eisentraut hacked the parser to accept it with or
> without empty parens. Thomas was not happy with that, and wants to
> take it out again in 7.3, but I'd prefer to see things left as-is.
> IMHO there's no real good reason *not* to accept the empty parens,
> and we'll keep getting this sort of question if we revert to the
> hard-line SQL-spec-and-nothing-but approach.
>
> regards, tom lane