Re: DecodeInterval fixes

On Sun, Aug 27, 2023 at 04:14:00PM -0400, Joseph Koshakow wrote:
> On Tue, Aug 22, 2023 at 12:58 PM Jacob Champion <jchampion(at)timescale(dot)com>
> wrote:
>> I wouldn't argue for backpatching, for sure, but I guess I saw this as
>> falling into the same vein as 5b3c5953 and bcc704b52 which were
>> already committed.
>
> I agree, I don't think we should try and backport this. As Jacob
> highlighted, we've merged similar patches for other date time types.
> If applications were relying on this behavior, the upgrade may be a
> good time for them to re-evaluate their usage since it's outside the
> documented spec and they may not be getting the units they're expecting
> from intervals like '1 day month'.

I felt like asking anyway. I have looked at the patch series and the
past compatibility changes in this area, and I kind of agree that this
seems like an improvement against confusing interval values. So, I
have applied 0001, 0002 and 0003 after more review.

0002 was a bit careless with the code indentation.

In 0003, I was wondering a bit if we'd better set parsing_unit_val to
false for AGO, but as we do a backward lookup and because after 0002
AGO can only be last, I've let the code as you have suggested, relying
on the initial value of this variable.
--
Michael