From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | t(dot)larionov(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16953: OOB access while converting "interval" to char |
Date: | 2021-04-09 10:42:46 |
Message-ID: | 20210409104246.vkeef6rbyevq46f3@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Apr 08, 2021 at 08:37:21PM +0900, Michael Paquier wrote:
> On Thu, Apr 08, 2021 at 07:04:03PM +0800, Julien Rouhaud wrote:
> > I'm fine with it too, although I'd probably go with [-13, 13] just to make sure
> > that there's isn't silly off-by-one mistake.
>
> Also, I guess that you'd just want to compile twice a modulo based on
> MONTHS_PER_YEAR to get the correct positive position in each array.
I'm not sure what you mean by that. We receive a pg_tm struct which can't
contain more than 12 in tm_mon right? And actually for intervals it will
reduce "12 months" to "1 year 0 month", so to_char previously didn't report
anything for 12 months either.
>
> > I'll just wait a bit to see if anyone else has any opinion on whether -1 month
> > should be January or December.
>
> Sure. If you can send an updated patch, that would be great.
Hearing no other opinion I went with -1 -> december and so on in attached v2.
I also fixed the "[-]12 months" case and updated the regression tests. Given
the extra code needed to deduce the correct array position I factorized DCH_RM
and DCH_rm.
Attachment | Content-Type | Size |
---|---|---|
v2-fix_rm.diff | text/plain | 3.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-04-09 10:58:51 | Re: BUG #16953: OOB access while converting "interval" to char |
Previous Message | Roman | 2021-04-09 06:52:10 | Update locks the row even if there is no row to update |