On Thu, Nov 16, 2023 at 2:03 AM Ashutosh Bapat
wrote:
>
>On Tue, Nov 14, 2023 at 4:39 PM Dean Rasheed
wrote:
>>
>> On Thu, 9 Nov 2023 at 12:49, Dean Rasheed
wrote:
>> >
>> > OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
>> >
>>
>> OK, I have
On Tue, Nov 14, 2023 at 4:39 PM Dean Rasheed wrote:
>
> On Thu, 9 Nov 2023 at 12:49, Dean Rasheed wrote:
> >
> > OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
> >
>
> OK, I have now pushed the main patch.
Thanks a lot Dean.
--
Best Wishes,
Ashutosh Bapat
On Thu, 9 Nov 2023 at 12:49, Dean Rasheed wrote:
>
> OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
>
OK, I have now pushed the main patch.
Regards,
Dean
On Thu, 9 Nov 2023 at 07:15, Ashutosh Bapat
wrote:
>
> Just to test whether that bug fix also fixes the failure seen with
> this patchset, I am attaching the patchset including the patch with
> the fix.
>
> 0001 - fix in other thread
> 0002 and 0003 are 0001 and 0002 in the previous patch set.
>
On Wed, 8 Nov 2023 at 06:56, jian he wrote:
>
> > On Tue, 7 Nov 2023 at 14:33, Dean Rasheed wrote:
> >
> > Ah, Windows Server didn't like that. Trying again with "INT64CONST(0)"
> > instead of just "0" in interval_um().
> >
> I found this:
> https://developercommunity.visualstudio.com/t/please-im
On Wed, Nov 8, 2023 at 7:42 AM Dean Rasheed wrote:
>
> On Tue, 7 Nov 2023 at 14:33, Dean Rasheed wrote:
> >
> > New version attached doing that, to run it past the cfbot again.
> >
>
> Ah, Windows Server didn't like that. Trying again with "INT64CONST(0)"
> instead of just "0" in interval_um().
>
On Mon, Oct 30, 2023 at 6:01 PM Ashutosh Bapat
wrote:
>
>
> Here's my version of commit message
>
> ```
> Support Infinite interval values
>
> Interval datatype uses the same input and output representation for
> infinite intervals as other datatypes representing
On Fri, Oct 27, 2023 at 2:07 PM Dean Rasheed wrote:
>
> On Wed, 4 Oct 2023 at 14:29, Ashutosh Bapat
> wrote:
> >
> > I think we should introduce interval_out_of_range_error() function on
> > the lines of float_overflow_error(). Later patches introduce more
> > places where we raise that error. We
On Wed, 4 Oct 2023 at 14:29, Ashutosh Bapat
wrote:
>
> I think we should introduce interval_out_of_range_error() function on
> the lines of float_overflow_error(). Later patches introduce more
> places where we raise that error. We can introduce the function as
> part of those patches.
>
I'm not
r(). Later patches introduce more
places where we raise that error. We can introduce the function as
part of those patches.
>
>
> 2. The various in_range() functions needed adjusting to handle
> infinite interval offsets.
>
> For timestamp values, I followed the precedent set by the
On Fri, Sep 22, 2023 at 2:35 PM jian he wrote:
>
> /* TODO: Handle NULL inputs? */
> since interval_avg_serialize is strict, so handle null would be like:
> if (PG_ARGISNULL(0)) then PG_RETURN_NULL();
That's automatically taken care of by the executor. Functions need to
handle NULL inputs if they
On Fri, Sep 22, 2023 at 3:49 PM Ashutosh Bapat
wrote:
>
> On Thu, Sep 21, 2023 at 7:21 PM Ashutosh Bapat
> wrote:
> >
> Hence I have changed interval_avg_deserialize() in 0007 to use
> CurrentMemoryContext instead of aggcontext. Rest of the patches are
> same as previous set.
>
> --
> Best Wishes
On Fri, 22 Sept 2023 at 08:49, Ashutosh Bapat
wrote:
>
> Following code in ExecInterpExpr makes it clear that the
> deserialization function is be executed in per tuple memory context.
> Whereas the aggregate's context is different from this context and may
> lives longer that the context in which
On Wed, Sep 20, 2023 at 8:23 PM Dean Rasheed wrote:
>
> On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
> wrote:
> >
> > 0005 - Refactored Jian's code fixing window functions. Does not
> > contain the changes for serialization and deserialization. Jian,
> > please let me know if I have missed anyth
> On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
> wrote:
> >
> > 0005 - Refactored Jian's code fixing window functions. Does not
> > contain the changes for serialization and deserialization. Jian,
> > please let me know if I have missed anything else.
> >
attached serialization and deserializati
On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
wrote:
>
> 0005 - Refactored Jian's code fixing window functions. Does not
> contain the changes for serialization and deserialization. Jian,
> please let me know if I have missed anything else.
>
That looks a lot neater. One thing I don't care for is
On Wed, Sep 20, 2023 at 5:44 PM Dean Rasheed wrote:
>
> On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
> >
> > So basically, do_interval_accum() could be simplified to:
> >
>
> Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
> sure that finite values don't sum to our rep
On Mon, Sep 18, 2023 at 5:09 PM Dean Rasheed wrote:
>
> On Wed, 13 Sept 2023 at 11:13, Ashutosh Bapat
> wrote:
> >
> > On Tue, Sep 12, 2023 at 2:39 PM Dean Rasheed
> > wrote:
> > >
> > > and it looks like the infinite interval
> > > inp
On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
>
> So basically, do_interval_accum() could be simplified to:
>
Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
sure that finite values don't sum to our representation of infinity,
as in interval_pl().
Regards,
Dean
On Wed, 20 Sept 2023 at 11:27, jian he wrote:
>
> if I remove IntervalAggState's element: MemoryContext, it will not work.
> so I don't understand what the above sentence means.. Sorry. (it's
> my problem)
>
I don't see why it won't work. The point is to try to simplify
do_interval_accum() as
On Sat, 16 Sept 2023 at 01:00, jian he wrote:
>
> I refactor the avg(interval), sum(interval), so moving aggregate,
> plain aggregate both work with +inf/-inf.
> no performance degradation, in fact, some performance gains.
>
I haven't reviewed this part in any detail yet, but I can confirm that
t
On Wed, 13 Sept 2023 at 11:13, Ashutosh Bapat
wrote:
>
> On Tue, Sep 12, 2023 at 2:39 PM Dean Rasheed wrote:
> >
> > and it looks like the infinite interval
> > input code is broken.
>
> The code required to handle 'infinit
On Thu, Sep 14, 2023 at 11:58 AM jian he wrote:
>
> - decade, century, and
> millennium).
> + decade, century, and
> millennium
> + for all types and hour and
> day just for interval).
It seems you have changed a paragraph from
https://www.postgresql.org/docs/current/datatype-datetime
On Wed, Sep 13, 2023 at 6:13 PM Ashutosh Bapat
wrote:
>
> to sum(). I am planning to work on this next week but in case somebody
> else wants to pick this up here are patches with other things fixed.
>
> --
> Best Wishes,
> Ashutosh Bapat
hi. some doc issues.
- decade, century, and
millenni
On Thu, 24 Aug 2023 at 14:51, Ashutosh Bapat
wrote:
>
> The patches still apply. But here's a rebased version with one white
> space error fixed. Also ran pgindent.
>
This needs another rebase, and it looks like the infinite interval
input code is broken.
I took a quick look,
Ashutosh Bapat writes:
> Fixed assertion in time_mi_time(). It needed to assert that the result
> is FINITE but it was doing the other way round and that triggered some
> failures in cfbot.
It's still not passing in the cfbot, at least not on any non-Linux
platforms. I believe the reason is that
On Sat, Apr 8, 2023 at 8:54 PM Joseph Koshakow wrote:
>
> I was also unable to find a definition of oscillating or monotonically
> increasing in this context. I used the existing timestamps and dates
> code to form my own definition:
>
> If there exists an two intervals with the same sign, such th
Hi Joseph,
On Mon, Apr 3, 2023 at 6:02 AM Joseph Koshakow wrote:
>
> I've attached a patch with all of the errcontext calls removed. None of
> the existing out of range errors have an errdetail call so I think this
> is more consistent. If we do want to add errdetail, then we should
> probably
Hi Joseph,
thanks for addressing comments.
On Sat, Apr 1, 2023 at 10:53 PM Joseph Koshakow wrote:
> So I added a check for FLOAT8_FITS_IN_INT64() and a test with this
> scenario.
I like that. Thanks.
>
> For what it's worth I think that 2147483647 months only became a valid
> interval in v15 as
036854775808 microseconds ago';
+-- overflowing using make_interval
+select make_interval(1, 2147483647, 2147483647, 1, 1, 1, 9223372036854.7759);
+select make_interval(-1, -2147483648, -2147483648, -1, -1, -1, -9223372036854.7759);
+SELECT make_interval(0, 0, 0, 0, 0, 0, 9223372036854.776000);
+
-
Joseph Koshakow writes:
>> I've added an errcontext to all the errors of the form "X out of
>> range".
Please note the style guidelines [1]:
errcontext(const char *msg, ...) is not normally called directly from
an ereport message site; rather it is used in error_context_stack
callbac
revious patches, no?
>They do not really seem per project style, and I'm not sure
>that they are helpful.)
Yes they were added in the previous patch,
v17-0003-Add-infinite-interval-values.patch. I also had the following
note about them.
>I've added an errcontext to all
Joseph Koshakow writes:
> I've attached a patch with these changes that is meant to be applied
> over the previous three patches. Let me know what you think.
Does not really seem like an improvement to me --- I think it's
adding more complexity than it removes. The changes in CONTEXT
messages ar
erval *) palloc(sizeof(Interval));
-
/*
* Subtracting two infinite timestamps with different signs results in an
* infinite interval with the same sign as the left operand. Subtracting
@@ -2812,6 +2811,7 @@ timestamp_mi(PG_FUNCTION_ARGS)
errcontext("while subtracting times
0:15.797 IST [136240] STATEMENT: select '5
> days'::interval * 'infinity'::float8;
> ERROR: interval out of range
>
> I think this should produce an infinite interval now. Attached patch
> to fix this, to be applied on top of your patch. With the patch
> #s
;::interval * 'infinity'::float8;
ERROR: interval out of range
I think this should produce an infinite interval now. Attached patch
to fix this, to be applied on top of your patch. With the patch
#select '5 days'::interval * 'infinity'::float8;
?column?
-
On Mon, Mar 20, 2023 at 3:16 AM Joseph Koshakow wrote:
>
>
>
> On Sun, Mar 19, 2023 at 5:13 PM Tom Lane wrote:
> >
> >Did you actually write "if TIMESTAMP_IS_NOBEGIN(dt2)" and not
> >"if (TIMESTAMP_IS_NOBEGIN(dt2))"? If the former, I'm not surprised
> >that pgindent gets confused. T
On Sun, Mar 26, 2023 at 1:28 AM Tom Lane wrote:
>
> I think you can take it as read that simple C test programs on modern
> platforms will exhibit IEEE-compliant handling of float infinities.
>
For the record, I tried the attached. It gives a warning at compilation time.
$gcc float_inf.c
float_i
On Sun, Mar 19, 2023 at 12:18 AM Joseph Koshakow wrote:
>
> The problem is that `secs = rint(secs)` rounds the seconds too early
> and loses any fractional seconds. Do we have an overflow detecting
> multiplication function for floats?
We have float8_mul() which checks for overflow. typedef doubl
On Sat, Mar 25, 2023 at 9:13 PM Joseph Koshakow wrote:
>
> On Fri, Mar 24, 2023 at 9:43 AM Ashutosh Bapat
> wrote:
> >
> >You don't need to do this, but looks like we can add DAYS_PER_WEEK macro
> > and
> >use it here.
>
> I've attached a patch with this new macro. There's probably tons
On Sat, 25 Mar 2023 at 15:59, Tom Lane wrote:
> Joseph Koshakow writes:
> > In terms of adding/subtracting infinities, the IEEE standard is pay
> > walled and I don't have a copy. I tried finding information online but
> > I also wasn't able to find anything useful. I additionally checked to see
Joseph Koshakow writes:
> In terms of adding/subtracting infinities, the IEEE standard is pay
> walled and I don't have a copy. I tried finding information online but
> I also wasn't able to find anything useful. I additionally checked to see
> the results of C++, C, and Java, and they all match w
In terms of adding/subtracting infinities, the IEEE standard is pay
walled and I don't have a copy. I tried finding information online but
I also wasn't able to find anything useful. I additionally checked to see
the results of C++, C, and Java, and they all match which increases my
confidence that
On Fri, Mar 24, 2023 at 9:43 AM Ashutosh Bapat
wrote:
>
>You don't need to do this, but looks like we can add DAYS_PER_WEEK
macro and
>use it here.
I've attached a patch with this new macro. There's probably tons of
places it can be used instead of hardcoding the number 7, but I'll save
t
On Sun, Mar 19, 2023 at 1:04 AM Joseph Koshakow wrote:
>
> The patches in this email should be rebased over master.
>
Reviewed 0001 -
Looks good to me. The new function is properly placed along with other
signed 64 bit functions. All existing calls to int64_multiply_add()
have been replaced with
syntactically incorrect.
Oh duh. I've been doing too much Rust development and did this without
thinking. I've attached a patch with a fix.
- Joe Koshakow
From d3543e7c410f83cbe3f3f3df9715025bc767fc5f Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 18 Mar 2023 13:59:34 -0400
Joseph Koshakow writes:
> I must have been doing something wrong because I tried again today and
> it worked fine. However, I go get a lot of changes like the following:
> - if TIMESTAMP_IS_NOBEGIN(dt2)
> - ereport(ERROR,
> -
> (errcode(ERRCODE_DATETIME_V
On Sat, Mar 18, 2023 at 3:55 PM Tom Lane wrote:
>
>Joseph Koshakow writes:
>> On Sat, Mar 18, 2023 at 3:08 PM Tom Lane wrote:
>>> More specifically, those are from running pg_indent with an obsolete
>>> typedefs list.
>
>> I must be doing something wrong because even after do
Joseph Koshakow writes:
> On Sat, Mar 18, 2023 at 3:08 PM Tom Lane wrote:
>> More specifically, those are from running pg_indent with an obsolete
>> typedefs list.
> I must be doing something wrong because even after doing that I get the
> same strange formatting. Specifically from the root dire
s -9223372036854775808 microseconds ago';
+-- overflowing using make_interval
+select make_interval(1, 2147483647, 2147483647, 1, 1, 1, 9223372036854.7759);
+select make_interval(-1, -2147483648, -2147483648, -1, -1, -1, -9223372036854.7759);
+
-- test that INT_MIN number is formatted properly
Joseph Koshakow writes:
> On Thu, Mar 9, 2023 at 12:42 PM Ashutosh Bapat
> wrote:
>> There are a lot of these diffs. PG code doesn't leave an extra space
>> between variable name and *.
> Those appeared from running pg_indent. I've removed them all.
More specifically, those are from running pg_
ROR,
-(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
- errmsg("interval out of range")));
+interval_um_internal(interval, result);
Shouldn't we incorporate these checks in interval_um_internal()? I don't think
INTERVAL_NOT_FINITE() covers all
17 Dec 2022 14:21:26 -0500
Subject: [PATCH] Add infinite interval values
This commit adds positive and negative infinite values to the interval
data type. The entire range of intervals with INT_MAX months or INT_MIN
months are reserved for infinite values. This makes checking finiteness
much simpl
On Sun, 15 Jan 2023 at 11:44, Joseph Koshakow wrote:
>
> On Sat, Jan 14, 2023 at 4:22 PM Joseph Koshakow wrote:
> I've gone ahead and updated the patch to only look at the months field.
> I'll submit this email and patch to the Feb commitfest.
It looks like this patch needs a (perhaps trivial)
e patch to only look at the months field.
I'll submit this email and patch to the Feb commitfest.
- Joe
From 123cdf534cc1a0e9a44e7dc8641d23e2c5b09e31 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17 Dec 2022 14:21:26 -0500
Subject: [PATCH] Add infinite interval values
This commi
al *span = PG_GETARG_INTERVAL_P(1);
TimeADT result;
+ if (INTERVAL_NOT_FINITE(span))
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("cannot subtract infinite interval from time")));
+
result = time - span->time;
result -= result / USEC
On Sun, Jan 8, 2023 at 11:17 PM jian he wrote:
>
>
>
> On Sun, Jan 8, 2023 at 4:22 AM Joseph Koshakow wrote:
>>
>> On Sat, Jan 7, 2023 at 3:05 PM Joseph Koshakow wrote:
>> >
>> > On Sat, Jan 7, 2023 at 3:04 PM Joseph Koshakow wrote:
>> > >
>> > > I think this patch is just about ready for revie
On Sun, Jan 8, 2023 at 4:22 AM Joseph Koshakow wrote:
> On Sat, Jan 7, 2023 at 3:05 PM Joseph Koshakow wrote:
> >
> > On Sat, Jan 7, 2023 at 3:04 PM Joseph Koshakow
> wrote:
> > >
> > > I think this patch is just about ready for review, except for the
> > > following two questions:
> > > 1. S
RG_INTERVAL_P(1);
TimeADT result;
+ if (INTERVAL_NOT_FINITE(span))
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("cannot add infinite interval to time")));
+
result = time + span->time;
result -= result / USECS_PER_DAY * USECS_PER_DAY;
if (r
.8334b9053f 100644
--- a/src/backend/utils/adt/date.c
+++ b/src/backend/utils/adt/date.c
@@ -2067,6 +2067,11 @@ time_pl_interval(PG_FUNCTION_ARGS)
Interval *span = PG_GETARG_INTERVAL_P(1);
TimeADT result;
+ if (INTERVAL_NOT_FINITE(span))
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VALUE_
On Thu, Jan 5, 2023 at 11:30 PM jian he wrote:
>
>
>
> On Fri, Jan 6, 2023 at 6:54 AM Joseph Koshakow wrote:
>>
>> Looks like some of the error messages have changed and we
>> have some issues with parsing "+infinity" after rebasing.
>
>
> There is a commit 2ceea5adb02603ef52579b568ca2c5aebed8735
On Fri, Jan 6, 2023 at 6:54 AM Joseph Koshakow wrote:
> Jian,
>
> I incorporated your changes and updated interval.out and ran
> pgindent. Looks like some of the error messages have changed and we
> have some issues with parsing "+infinity" after rebasing.
>
> - Joe
>
Looks like some of the erro
sg("cannot add infinite interval to time")));
+
result = time + span->time;
result -= result / USECS_PER_DAY * USECS_PER_DAY;
if (result < INT64CONST(0))
@@ -2085,6 +2090,11 @@ time_mi_interval(PG_FUNCTION_ARGS)
Interval *span = PG_GETARG_INTERVAL_P(1);
TimeADT result;
On Thu, Jan 5, 2023 at 5:20 AM jian he wrote:
>
>
>
> On Wed, Jan 4, 2023 at 10:13 PM jian he wrote:
>>
>>
>>
>> I don't know how to generate an interval.out file.
Personally I just write the .out files manually. I think it especially
helps as a way to double-check that the results are what you
E(span) && TIMESTAMP_IS_NOEND(timestamp)))
+ TIMESTAMP_NOEND(result);
+
+else if ((!INTERVAL_NOT_FINITE(span) && TIMESTAMP_NOT_FINITE(timestamp))
+ || (INTERVAL_NOT_FINITE(span) && !TIMESTAMP_NOT_FINITE(timestamp)))
+ ereport(ERROR,
+
On Tue, Jan 3, 2023 at 6:14 AM Joseph Koshakow wrote:
> I have another patch, this one adds validations to operations that
> return intervals and updated error messages. I tried to give all of the
> error messages meaningful text, but I'm starting to think that almost all
> of them should just sa
FINITE(span))
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("cannot add infinite interval to time")));
+
result = time + span->time;
result -= result / USECS_PER_DAY * USECS_PER_DAY;
if (result < INT64CONST(0))
@@ -2091,6 +2096,11 @@ time_mi_interval(PG_FUNCTION_
x 1cf7c7652d..c6259cd9c1 100644
--- a/src/backend/utils/adt/date.c
+++ b/src/backend/utils/adt/date.c
@@ -2073,6 +2073,11 @@ time_pl_interval(PG_FUNCTION_ARGS)
Interval *span = PG_GETARG_INTERVAL_P(1);
TimeADT result;
+ if (INTERVAL_NOT_FINITE(span))
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VA
ated post
> (https://math.stackexchange.com/questions/181304/what-is-infinity-divided-by-infinity).
Good point, I agree this should return an error. We also need to
properly handle multiplication and division of infinite intervals by
float8 'nan'. My patch is returning an infinite int
On 12/31/22 06:09, jian he wrote:
Since in float8 you can use '+inf', '+infinity', So should we also make
interval '+infinity' valid?
Yes.
Also in timestamp. '+infinity'::timestamp is invalid, should we make it
valid.
Yes, we should. I wrote a trivial patch for this a while ago but it
ap
On Fri, Dec 30, 2022 at 10:47 PM Joseph Koshakow wrote:
> I have another update, I cleaned up some of the error messages, fixed
> the horology tests, and ran pgindent.
>
> - Joe
>
Hi, there.
Since in float8 you can use '+inf', '+infinity', So should we also make
interval '+infinity' valid?
Also
+ ereport(ERROR,
+(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("cannot add infinite interval to time")));
+
result = time + span->time;
result -= result / USECS_PER_DAY * USECS_PER_DAY;
if (result < INT64CONST(0))
@@ -2091,6 +2096,11 @@ time_mi_interval(PG
n, itm);
+ EncodeInterval(itm, IntervalStyle, buf);
+ }
result = pstrdup(buf);
PG_RETURN_CSTRING(result);
@@ -1352,6 +1367,13 @@ AdjustIntervalForTypmod(Interval *interval, int32 typmod,
INT64CONST(0)
};
+ /*
+ * Infinite interval after being subjected to typmod conversion remains
+ * inf
he
> error messages as TODOs. Hopefully it's a good reference for the
> implementation.
>
> > Adding infinite interval to an infinite timestamp with opposite
> > direction is not going to yield 0 but some infinity. Since we are adding
> > interval to the timesta
tion.
> Adding infinite interval to an infinite timestamp with opposite
> direction is not going to yield 0 but some infinity. Since we are adding
> interval to the timestamp the resultant timestamp is an infinity
> preserving the direction.
I think I disagree with this. Tom Lane in one o
more than an year. Now that I have someone else showing an interest,
> it's time for it to face the world. Rebased it, fixed conflicts.
>
> PFA patch implementing infinite interval. It's still WIP, there are
> TODOs in the code and also the commit message lists things that are
or it to face the world. Rebased it, fixed conflicts.
PFA patch implementing infinite interval. It's still WIP, there are
TODOs in the code and also the commit message lists things that are
known to be incomplete. You might want to assess expected output
carefully
On Sun, Dec 11, 2022 a
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
https://www.postgresql.org/message-id/flat/CANP8%2BjKTxQh4Mj
78 matches
Mail list logo
