Re: DecodeInterval fixes - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: DecodeInterval fixes
Date
Msg-id CAAvxfHf1PV1X6VmcrDY7MSZSDVVXQ9FHTEB6wnET+zFSACUHvA@mail.gmail.com
Whole thread Raw
In response to Re: DecodeInterval fixes  (Jacob Champion <jchampion@timescale.com>)
Responses Re: DecodeInterval fixes
List pgsql-hackers


On Tue, Aug 22, 2023 at 12:58 PM Jacob Champion <jchampion@timescale.com> wrote:
>
> On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier <michael@paquier.xyz> wrote:
> > 0002 and 0003 make this stuff fail, but isn't there a risk that this
> > breaks applications that relied on these accidental behaviors?
> > Assuming that this is OK makes me nervous.
>
> 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'.

Thanks,
Joe Koshakow

pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: list of acknowledgments for PG16
Next
From: Heikki Linnakangas
Date:
Subject: Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG