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.