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 time that support
> infinity. An i
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
On Fri, Sep 29, 2023 at 12:43 PM Dean Rasheed wrote:
>
> I think that part is now ready to commit, and I plan to push this fix
> to make_interval() separately, since it's really a bug-fix, not
> related to support for infinite intervals. In line with recent
> precedent, I don't think it's worth ba
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
> > > input code is broken.
> >
> > The code required to handle 'inf
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 'infinity' as an input value was removed by
> d6d1430f404386162831bc32906ad174b200
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, and had a couple of
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
On Sun, Apr 2, 2023 at 6:54 PM Tom Lane wrote:
>
>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
>
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
>On Sun, Apr 2, 2023 at 5:36 PM Tom Lane wrote:
>
>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
>
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
> > This code is duplicated in timestamp_pl_interval(). We could create a
function
> > to encode the infinity handling rules and then call it in these two
places. The
> > argument types are different, Timestamp and TimestampTz viz. which map
to in64,
> > so shouldn't be a problem. But it will be sl
I hurried too much on the previous patch. It introduced other
problems. Attached is a better patch and also fixes problem below
#select 'infinity'::interval * 0;
?column?
--
infinity
(1 row)
with the patch we see
#select 'infinity'::interval * 0;
2023-03-31 18:00:43.131 IST [240892] ERRO
On Tue, Mar 28, 2023 at 7:17 PM Ashutosh Bapat
wrote:
> make sure that every
> operator that interval as one of its operands or the result has been
> covered in the code.
time_mi_time - do we want to add an Assert to make sure that this
function does not produce an Interval structure which looks
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
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. The parentheses are required by the
>C standard. Your code might acc
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
On Sat, Mar 18, 2023 at 3:08 PM Tom Lane wrote:
> Joseph Koshakow writes:
>> On Thu, Mar 9, 2023 at 12:42 PM Ashutosh Bapat <
ashutosh.bapat@gmail.com>
>> wrote:
>>> There are a lot of these diffs. PG code doesn't leave an extra space
>>> between variable name and *.
>
>> Those appeared from
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_
Hi Joseph,
Thanks for working on the patch. Sorry for taking so long to review
this patch. But here's it finally, review of code changes
static pg_tz *FetchDynamicTimeZone(TimeZoneAbbrevTable *tbl, const datetkn *tp,
- DateTimeErrorExtra *extra);
+
On Wed, Mar 1, 2023 at 3:03 PM Gregory Stark (as CFM)
wrote:
>
>It looks like this patch needs a (perhaps trivial) rebase.
Attached is a rebased patch.
>It sounds like all the design questions are resolved so perhaps this
>can be set to Ready for Committer once it's rebased?
There h
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)
On Sat, Jan 14, 2023 at 4:22 PM Joseph Koshakow wrote:
>
> At this point the patch is ready for review again except for the one
> outstanding question of: Should finite checks on intervals only look at
> months or all three fields?
>
> - Joe
I've gone ahead and updated the patch to only look at t
Ok, I've updated the patch to handle every function that inputs or
outputs intervals, as well as added some tests. In the process I
noticed that some of the existing date/timestamp/timestamptz don't
handle infinite values properly. For example,
postgres=# SELECT age('infinity'::timestamp);
age
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
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. Should finite checks on intervals only look at months or all three
> >
On Sat, Jan 7, 2023 at 3:04 PM Joseph Koshakow wrote:
>
> 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
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
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
From 4bf672f9079322cffde635dff2078582fca55f09 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date
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
On Wed, Jan 4, 2023 at 10:13 PM jian he wrote:
>
>
> 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
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
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 say "interval out of range". The current approach
may reveal some
On Mon, Jan 2, 2023 at 1:21 PM Joseph Koshakow wrote:
>
> On Sat, Dec 31, 2022 at 12:09 AM jian he wrote:
> > In float8, select float8 'inf' / float8 'inf' return NaN. Now in your patch
> > select interval 'infinity' / float8 'infinity'; returns infinity.
> > I am not sure it's right. I found t
On Sat, Dec 31, 2022 at 12:09 AM jian he wrote:
> In float8, select float8 'inf' / float8 'inf' return NaN. Now in your patch
> select interval 'infinity' / float8 'infinity'; returns infinity.
> I am not sure it's right. I found this related post
> (https://math.stackexchange.com/questions/181
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
I have another update, I cleaned up some of the error messages, fixed
the horology tests, and ran pgindent.
- Joe
From 518c59be586abf5779c5727c2117b6a46b466503 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17 Dec 2022 14:21:26 -0500
Subject: [PATCH] This is WIP.
Following things are
Hi Ashutosh,
I ended up doing some more work on this today. All of the major
features should be implemented now. Below are what I think are the
outstanding TODOs:
- Clean up error messages and error codes
- Figure out how to correctly implement interval_part for infinite
intervals. For now I prett
On Sat, Dec 17, 2022 at 2:34 PM Joseph Koshakow wrote:
>
> Hi Ashutosh,
>
> I've added tests for all the operators and functions involving
> intervals and what I think the expected behaviors to be. The
> formatting might be slightly off and I've left the contents of the
> error messages as TODOs.
Hi Ashutosh,
I've added tests for all the operators and functions involving
intervals and what I think the expected behaviors to be. The
formatting might be slightly off and I've left the contents of the
error messages as TODOs. Hopefully it's a good reference for the
implementation.
> Adding inf
On Mon, Dec 12, 2022 at 8:05 AM Ashutosh Bapat
wrote:
>
> Hi Joseph,
> I stumbled upon this requirement a few times. So I started working on
> this support in my spare time as a hobby project to understand
> horology code in PostgreSQL. This was sitting in my repositories for
> more than an year.
Hi Joseph,
I stumbled upon this requirement a few times. So I started working on
this support in my spare time as a hobby project to understand
horology code in PostgreSQL. This was sitting in my repositories for
more than an year. Now that I have someone else showing an interest,
it's time for it
77 matches
Mail list logo
