> If full SQL92 implementation of INTERVAL would be a welcome addition,
> could it be added as a TODO item? I would like to work on it, since I
> want to use some features that are not currently supported.
...
> Valid SQL92 syntax that is not currently supported:
...
> junk=# SELECT INTERVAL '1990' YEAR(4);
...
So far, I've had shift/reduce troubles trying to have a trailing
qualifier field like this.
> junk=# SELECT INTERVAL -'1-1' YEAR TO MONTH;
> ERROR: parser: parse error at or near "YEAR"
A leading sign in front of a string-like field? Yuck.
...
> Valid interval value format not currently supported:
> year-month
I'll look at accepting this for the current INTERVAL type too.
> Since there are aspects of SQL92 interval representation that clash
> with the current implementation, I would suggest that current
> practice be followed unless SQL92 syntax is used. So a field that
> is of type INTERVAL without qualification would continue to work
> as it does now (except that I would like to implement range checking).
I like this point. Really, SQL99 intervals are a bit unwieldy, though
they do have "extra features" which someone might find useful.
> The main difference would be in the output format...
> ... parts of either year-month or
> day hour:minute:second.fractional_second
We could probably support this format (now that you have described it to
us) at least for the "SQL" datestyle even for the existing INTERVAL
type.
> according to the field definition, without any words (i.e.: "1 03:46:40.00"
> instead of "1 day 03:46:40.00", and "3-5" instead of "3 years 5 mons").
> All parts within the range will be shown, even if they are trailing zeros.
This set of conventions might let the date/time parser do a complete
job. I put in the "days" text label to reduce the ambiguity of a single,
unlabeled integer.
> What do you think?
Have you gotten started yet? Finished yet?? ;)
- Thomas