From: | Thomas Lockhart <thomas(at)fourpalms(dot)org> |
---|---|
To: | Jon Lapham <lapham(at)extracta(dot)com(dot)br> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: On using "date 'XXX' + interval 'XXX'" vs "date 'XXX'" |
Date: | 2002-05-20 16:22:10 |
Message-ID: | 3CE922B2.B3AE8D95@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > Try coercing the sum result back to a date.
...
> PS: Is this optimizable? (ie: have the coersion be implicit in
> situations like this). It sure seems like it is a good candidate...
Not at the parser or optimizer level. You *could* have had hours,
minutes, or seconds in that interval value you specified, in which case
you would be truncating to get back to date. We'd need more
infrastructure to somehow know how to optimize something like that.
Or, we could split the INTERVAL type into the (ugh) bunch-o-types
envisioned by the SQL standard. YEAR, MONTH, YEAR TO MONTH, and DAY
intervals could be converted directly to dates rather than timestamps.
This would allow the optimizer to know what the output range would be,
whereas now the range info is just used for input and output (and is
usually a don't-care internally since the other fields are zeros).
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Brian McCane | 2002-05-20 16:35:07 | Re: Interval to number |
Previous Message | Stephan Szabo | 2002-05-20 16:13:17 | Re: Referential Integrity. |