On Sun, Dec 11, 2022 at 10:29 AM Joseph Koshakow wrote:
>
> Hi all,
>
> Attached is a patch to fix a parsing error for date-time types that
> allow dangling units in the input. For example,
> `date '1995-08-06 m y d'` was considered a valid date and the dangling
&g
fbcf39211fc7a379ea021160298604694383d56c Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 10 Dec 2022 18:59:26 -0500
Subject: [PATCH] Handle dangling units in date-time input
DecodeDateTime and DecodeTimeOnly allowed dangling unit types on input
without returning an error. For example, `date '1995-08-06 m y d
Hi all,
There have been multiple threads in the past discussing infinite
intervals:
https://www.postgresql.org/message-id/flat/4EB095C8.1050703%40agliodbs.com
https://www.postgresql.org/message-id/flat/200101241913.f0OJDUu45423%40hub.org
On Sun, Apr 3, 2022 at 3:06 PM Tom Lane wrote:
> That buildfarm machine is pretty slow, so I'm not in a hurry to test
> it manually either. However, now that we realize the issue is about
> whether strtod(".") produces EINVAL or not, I think we need to fix
> all the places in datetime.c that are
On Sun, Apr 3, 2022 at 12:44 PM Joseph Koshakow wrote:
>
> On Sun, Apr 3, 2022 at 12:30 PM Tom Lane wrote:
> >
> > Joseph Koshakow writes:
> > > So I think we need to check that endptr has moved both after
> > > the call to strtoi64() and strtod()
On Sun, Apr 3, 2022 at 12:30 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > So I think we need to check that endptr has moved both after
> > the call to strtoi64() and strtod().
>
> I'm not sure we need to do that explicitly, given that there's
> a check
On Sun, Apr 3, 2022 at 12:03 PM Tom Lane wrote:
>
> I wrote:
> > Joseph Koshakow writes:
> >> I think I know that the issue is. It's with `ParseISO8601Number` and
> >> the minutes field "1.".
> >> Previously that function parsed the enti
On Sun, Apr 3, 2022 at 3:09 AM Tom Lane wrote:
>
> I wrote:
> > Cool. I've pushed the patch.
>
> Hmm ... buildfarm's not entirely happy [1][2][3]:
>
> diff -U3
> /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/expected/interval.out
>
On Sat, Apr 2, 2022 at 3:08 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > Ok I actually remember now, the issue is with the rounding
> > code in AdjustFractMicroseconds.
> > ...
> > I believe it's possible for `frac -= usec;` to result in a value greater
he attached patch (which would be
applied on top of your v10 patch) seems to fix the issue. Feel
free to ignore it if you're already working on a fix.
- Joe
From f43d27142a76fcbabf49e45b9457f8376744e759 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 2 Apr 2022 14:42:18 -0400
Subj
On Sat, Apr 2, 2022 at 2:22 PM Joseph Koshakow wrote:
>
> On Sat, Apr 2, 2022 at 1:29 PM Joseph Koshakow wrote:
> >
> > On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
> > >
> > > Joseph Koshakow writes:
> > > > * The existing code for rou
On Sat, Apr 2, 2022 at 1:29 PM Joseph Koshakow wrote:
>
> On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
> >
> > Joseph Koshakow writes:
> > > * The existing code for rounding had a lot of int to double
> > > casting and vice versa. I *think* that doubles ar
On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > * The existing code for rounding had a lot of int to double
> > casting and vice versa. I *think* that doubles are able to completely
> > represent the range of ints. However doubles a
On Mon, Mar 21, 2022 at 8:31 PM Tom Lane wrote:
> This isn't applying per the cfbot; looks like it got sideswiped
> by 9e9858389. Here's a quick rebase. I've not reviewed it, but
> I did notice (because git was in my face about this) that it's
> got whitespace issues. Please try to avoid
On Tue, Mar 15, 2022 at 3:46 AM Julien Rouhaud wrote:
> On Tue, Mar 15, 2022 at 12:54:58PM +0530, Prabhat Sahu wrote:
> >
> > Is there any specific purpose we are holding the hours as an increasing
> > number beyond 24 hours also?
>
> Yes, you can't blindly assume that adding 24 hours will always
I just realized another issue today. It may have been obvious from one
of Tom's earlier messages, but I'm just now putting the pieces
together.
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
> Also, I notice that there's an overflow hazard upstream of here,
> in interval2tm:
>
> regression=#
t64 conversions. I tried to model it after the parsing done
in DecodeInterval, though I would appreciate extra scrutiny here.
- Joe Koshakow
From a2afce720fb65b87638a634078067a796a639ddc Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Mon, 28 Feb 2022 22:52:55 -0500
Subject: [PATCH] Rew
Just checking because I'm not very familiar with the process,
are there any outstanding items that I need to do for this patch?
- Joe Koshakow
On Thu, Feb 24, 2022 at 4:47 AM Aleksander Alekseev
wrote:
> Extracting an epoch from an interval is quite a strange case since intervals
> are not connected to any specific dates.
I agree, I think it's a weird use case and that it's probably not
worth fixing. Though it was fun for me to try.
On Wed, Feb 23, 2022 at 7:42 PM Joseph Koshakow wrote:
>
> Hi all,
>
> I noticed something odd when going through some
> of the Interval code. The DAYS_PER_YEAR constant
> is defined in src/include/datatype/timestamp.h.
> > #define DAYS_PER_YEAR365.25/* assumes le
Hi all,
I noticed something odd when going through some
of the Interval code. The DAYS_PER_YEAR constant
is defined in src/include/datatype/timestamp.h.
> #define DAYS_PER_YEAR365.25/* assumes leap year every four years */
We execute the EXTRACT and date_part functions in
On Sun, Feb 20, 2022 at 6:37 PM Tom Lane wrote:
> Couple of quick comments:
Thanks for the comments Tom, I'll work on fixing these and submit a
new patch.
> * The uses of tm2itm make me a bit itchy. Is that sweeping
> upstream-of-there overflow problems under the rug?
I agree, I'm not super
copied and pasted
from other files. The code seemed out of date from those other files, so
I tried to bring it up to date and add my changes.
- Joe Koshakow
From f678ee1bdcd6e075f1b1c771e6d5f6b3f9089086 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Fri, 11 Feb 2022 14:18:32 -0500
Subject
Copying over a related thread here to have info all in one place.
It's a little fragmented so sorry about that.
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > When formatting the output of an Interval, we call abs() on the hours
> > fie
On Sat, Feb 19, 2022 at 12:00 PM Tom Lane wrote:
> I think that messing with struct pg_tm might have too many side-effects.
> However, pg_tm isn't all that well adapted to intervals in the first
> place, so it'd make sense to make a new struct specifically for interval
> decoding.
Yeah that's a
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > When formatting the output of an Interval, we call abs() on the hours
> > field of the Interval. Calling abs(INT_MIN) returns back INT_MIN
> > causing the output to contain two '-' charac
:
postgres=# SELECT INTERVAL '-2147483648 hrs';
interval
--2147483648:00:00
(1 row)
Cheers,
Joe Koshakow
From 720f0903c71a428695672aa866fc8fb0146a472e Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Thu, 17 Feb 2022 21:57:48 -0500
Subject: [PATCH] Fix
: Joseph Koshakow
Date: Fri, 11 Feb 2022 14:18:32 -0500
Subject: [PATCH] Check for overflow when decoding an interval
When decoding an interval there are various date units which are
aliases for some multiple of another unit. For example a week is 7 days
and a decade is 10 years. When decoding
On Sun, Feb 13, 2022 at 5:12 PM Joseph Koshakow wrote:
>
> Attached is a new version switching from ints to bools, as requested.
>
> - Joe Koshakow
Tom, Andres,
Thanks for your feedback! I'm not super familiar with the process,
should I submit this thread to the commitfest o
3ad95b4d4fc3ef2542d8a941 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 13 Feb 2022 13:26:16 -0500
Subject: [PATCH] Check for overflow in justify_interval functions
justify_interval, justify_hours, and justify_days didn't check for
overflow when moving hours to days or days to hours
patch.
- Joe
From 8ff8302b90c790d967f770286dfa54432f63662c Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 13 Feb 2022 13:26:16 -0500
Subject: [PATCH] Check for overflow in justify_interval functions
justify_interval, justify_hours, and justify_days didn't check for
overflow when moving hours to day
On Mon, Feb 14, 2022 at 2:15 PM Nathan Bossart wrote:
> Makes sense. So we could likely avoid it for justify_interval, but the
> others are at the mercy of the interval implementation.
I'm not entirely sure what you mean by "it", but for both
justify_interval and justify_days this commit throws
Attached is a new version switching from ints to bools, as requested.
- Joe Koshakow
From af8f030ad146602b4386f77b5664c6013743569b Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Fri, 11 Feb 2022 14:18:32 -0500
Subject: [PATCH] Check for overflow when decoding an interval
When decoding
00:00:00 2001
From: Joseph Koshakow
Date: Fri, 11 Feb 2022 14:18:32 -0500
Subject: [PATCH] Check for overflow when decoding an interval
When decoding an interval there are various date units which are
aliases for some multiple of another unit. For example a week is 7 days
and a decade is 10 years
I mentioned this issue briefly in another thread, but the
justify_interval, justify_days, and justify_hours functions
all have the potential to overflow. The attached patch fixes
this issue.
Cheers,
Joe Koshakow
From 4400f2e6886097e3b75d455aeec1ffa9cbc88510 Mon Sep 17 00:00:00 2001
From: Joseph
On Sat, Feb 12, 2022 at 10:51 PM Andres Freund wrote:
> Any reason for using int return types?
>
> particularly since the pg_*_overflow stuff uses bool?
I chose int return types to keep all these methods
consistent with DecodeInterval, which returns a
non-zero int to indicate an error. Though I
On Fri, Feb 11, 2022 at 4:58 PM Joseph Koshakow wrote:
>
> Tom Lane writes:
> > Joseph Koshakow writes:
> > > The attached patch fixes an overflow bug in DecodeInterval when applying
> > > the units week, decade, century, and millennium. The overflow check
Tom Lane writes:
> Joseph Koshakow writes:
> > The attached patch fixes an overflow bug in DecodeInterval when applying
> > the units week, decade, century, and millennium. The overflow check logic
> > was modelled after the overflow check at the beginning of `int
> &g
first patch, so apologies if I screwed up the process somewhere.
- Joe Koshakow
From b3c096039a4684646806e2959d7ac9318504b031 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Fri, 11 Feb 2022 14:18:32 -0500
Subject: [PATCH] Check for overflow when decoding an interval
When decoding
101 - 139 of 139 matches
Mail list logo
