Dmitry wrote:
> > 'YESTERDAY', 'TODAY' and 'TOMORROW'
> > These are not context variables, but serve the same purpose. See 'NOW',
> > which is also documented under Context variables (quotes and all).
>
> They can behave as either literals substituted immediately (timestamp
> 'today') or as context variables (cast('today' as timestamp)). Quite
> weird and perhaps even annoying, I know.
Yes, we'll have to document this clearly:
- When used with CAST() they are evaluated each time the code is executed and
return the current date (or, in the case of 'now', timestamp). In this case,
they are more up-to-date than the CURRENT_<DATETIME> variables, which are
evaluated once per request (thus staying the same during a PSQL module
execution, for instance).
- When used as shorthand casts / datetime literals they are evaluated only
once: at parse/prepare time. In this case, they are often *less* up-to-date
than the CURRENT_<DATETIME> variables, because the latter are refreshed every
time a prepared query is executed again.
> > One difference is that 'NOW' can be cast to any date/time type, and these
> > three only to DATE and TIMESTAMP.
>
> Not completely true:
>
> time 'today' -- error
> cast(timestamp 'today' as time) -- 00:00:00.0000
Hmm, but you don't cast 'today' to a time value here. You cast it to a
timestamp (adding a zero time), and then you cast the timestamp to a time value
(dropping today's date and retaining the zero time).
> In this regard, I don't like referring to date/time/timestamp keywords
> prior to a string as to "shorthand casts". In fact, it's the only
> syntactically correct way to specify a date/time literal. Numerics can
> be represented normally, strings are enclosed in quotes, but there's
> nothing for dates/times. So the ANSI committee has invented a special
> prefix (data type name was used) following by the string literal which
> is treated as a date/time literal in this case. So it's a part of the
> language grammar rather than some operation. That said, it does really
> work like a cast, so I don't know how to document it properly :-)
> Especially considering 'NOW' etc that do work like a function.
You're right, I just read that part of the standard. Still, I consider 'today'
etc. string literals (and so does the standard), so I think the interpretation
of "date 'today'" as a cast operation is logical. OTOH, what you write above
does explain why e.g.
select date MyDateTimeField from MyTable
is illegal. If these prefixes were real cast operators, such queries would be
valid. As would "select int YourFloatField from YourTable" etc. Actually, I
wouldn't mind if this syntax were supported; I hate writing out CAST()
expressions! :-)
Cheers,
Paul Vinkenoog
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs
