On Sun, Aug 27, 2023 at 04:14:00PM -0400, Joseph Koshakow wrote: > On Tue, Aug 22, 2023 at 12:58 PM Jacob Champion <jchamp...@timescale.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
signature.asc
Description: PGP signature
