Re: Constant propagation and similar issues

On Mon, Sep 11, 2000 at 10:47:04AM -0500, Ross J. Reedstrom wrote:
> On Mon, Sep 11, 2000 at 11:15:58AM -0400, Tom Lane wrote:
> > 
> > Most of the datetime operations are not considered constant-foldable.
> > The reason is that type timestamp has a special value CURRENT that
> > is a symbolic representation of current time (this is NOT what now()
> > produces, but might be thought of as a data-driven way of invoking
> > now()).  This value will get reduced to a simple constant when it is
> > fed into an arithmetic operation.  Hence, premature evaluation changes
> > the results and would not be a correct optimization.
> > 
> > AFAIK hardly anyone actually uses CURRENT, and I've been thinking of
> > proposing that we eliminate it to make the world safe for constant-
> > folding timestamp operations.  (Thomas, any comments here?)
> > 
> 
> I checked the ansi SQL'99 docs, and CURRENT as a date special constant
> is not a part of the standard (although CURRENT is a keyword: it is 
> used in the context of cursors)
> 

Following up to myself: 

Ah, I had forgotten that CURRENT is a magic value, like 'infinity'.

The standard does specify in section 6.19:

CURRENT_DATE, CURRENT_TIME, LOCALTIME, CURRENT_TIMESTAMP, and LOCALTIMESTAMP

as <datetime value function>

Which are currently implemented as generating the special value 'CURRENT',
which then get's stored in the column. This strikes me as _not_ standards
compliant.  What do other DB's do with these? I think that they should
be equivalent to now(), returning a static date that is stored.

I do find the timestamp special values 'infinity' and '-infinity' very
useful, but have never found a use for 'current'.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005