Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle

Tom Lane wrote:
> Another thought here ... I'm looking at the sign hack
> +                 if (IntervalStyle == INTSTYLE_SQL_STANDARD &&
>.... 
> and not liking it very much.  Yes, it does the intended thing for strict
> SQL-spec input, but it seems to produce a bunch of weird corner cases
> for non-spec input.  Consider [... many examples ...]
> 
> I'm inclined to think we need a more semantically-based instead of
> syntactically-based rule.  For instance, if first field is negative and
> no other field has an explicit sign, then force all fields to be <= 0.
> This would probably have to be applied at the end of DecodeInterval
> instead of on-the-fly within the loop.
> 
> Thoughts?

I'll take a step back and think about that....

Yes, at first glance I think that approach is better; but we'd need
to make sure not to apply the rule too enthusiastically on traditional
postgres intervals; or worse, ones that mix sql standardish and postgres
values  For example  dish=# select interval '-1 1:1 1 years';           interval  --------------------------   1 year
-1days +01:01:00  (1 row)
 
that 8.3 accepts. (or do we not care about those)?

In some ways I wonder if we should have 2 totally separate parsing
one for the SQL standard ones, and one for the postgres.
That would avoid some other confusing inputs like:  select interval '-00-01 1 years';  select interval '1-1 hours';
selectinterval '1:1 years';  select interval '1 hours 1-1 1 years'
 
that are currently accepted.