evious one and may not be worth the
effort. If you feel that it's worth it I can clean it up, otherwise
I'll drop it.
Thanks,
Joe Koshakow
From 936a9e3509867574633882f5c1ec714d2f2604ec Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 4 May 2024 10:12:37 -0400
Subject: [PATCH] Prevent name confl
patch.
Does anyone think this is worth fixing? If so I can submit it to the
current commitfest.
Thanks,
Joe Koshakow
From 50f6e73d9bc1e00ad3988faa80a84af70aef Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 4 May 2024 10:12:37 -0400
Subject: [PATCH] Prevent name conflicts wh
Hi all,
Immediately after sending this I realized that timestamptz suffers
from the same problem. Attached is an updated patch that fixes
timestamptz too.
Thanks,
Joe Koshakow
On Sat, Apr 27, 2024 at 10:59 PM Joseph Koshakow wrote:
> Hi all,
>
> Attached is a patch that fixes some
it early.
I couldn't find any existing timestamp plus interval tests so I stuck
a new tests in `timestamp.sql`. If there's a better place, then
please let me know.
Thanks,
Joe Koshakow
From 4350e540fd45d3c868a36021ae79ce533bdeab5f Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 27 Apr 2024
o
>me to probably not be worth back-patching.)
Agreed, this seems like a pretty rare overflow/underflow.
Thanks,
Joe Koshakow
From 470aa9c8898b4e4ebbad97d6e421377b9a3e03cf Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Tue, 13 Feb 2024 13:06:13 -0500
Subject: [PATCH] Fix overflow hazard
&& src/tools/pgindent/pgindent
src/backend/utils/adt/timestamp.c`
Thanks,
Joe Koshakow
From 389b0d1e3f3cca6fca1e45fdd202b1ca066326c2 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Tue, 13 Feb 2024 13:06:13 -0500
Subject: [PATCH] Fix overflow hazard in interval rounding
This commit fixes
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, Aug 22, 2023 at 12:58 PM Jacob Champion
wrote:
>
> On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier
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
On Mon, Jul 10, 2023 at 4:32 PM Nathan Bossart
wrote:
> Okay. Here's a new patch set in which I believe I've addressed all
> feedback. I didn't keep the GetAuthenticatedUserIsSuperuser() helper
> function around, as I didn't see a strong need for it.
Thanks, I think the patch set looks good to
On Sun, Jul 9, 2023 at 1:03 PM Joseph Koshakow wrote:
>> * Only a superuser may set auth ID to something other than himself
> Is "auth ID" the right term here? Maybe something like "Only a
> superuser may set their session authorization/ID to something other
&g
00 2001
From: Joseph Koshakow
Date: Sun, 9 Jul 2023 13:12:16 -0400
Subject: [PATCH 1/3] Remove dead code in DecodeInterval
This commit removes dead code for handling unit type RESERVE. There
used to be a unit called "invalid" that was of type RESERVE. At some
point that unit was removed
rrect value [0], and potentially is
not used internally for anything.
I've rebased my changes over your patch and attached them both.
[0]
https://www.postgresql.org/message-id/CAAvxfHcxH-hLndty6CRThGXL1hLsgCn%2BE3QuG_4Qi7GxrHmgKg%40mail.gmail.com
From 2e1689b5fe384d675043beb9df8eff49a0ff436e Mon Sep 17
ation.
I've attached a patch with this change.
Thanks,
Joe Koshakow
From cb0198524d96068079e301a6785301440f3be3aa Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Thu, 15 Jun 2023 14:53:11 -0400
Subject: [PATCH] Prevent non-superusers from altering session auth
Previously, if a user connected with
I've discovered an issue with this approach. Let's say you have some
session open that is connected as a superuser and you run the following
commands:
- CREATE ROLE r1 LOGIN SUPERUSER;
- CREATE ROLE r2;
- CREATE ROLE r3;
Then you open another session connected with user r1 and run the
og lookup is only done if
userid != AuthenticatedUserId. So RESET SESSION AUTHORIZATION with a
concurrently dropped role will no longer FATAL.
Thanks,
Joe
On Sat, Jul 1, 2023 at 11:33 AM Joseph Koshakow wrote:
> >> That might be a good change? If the original authenticated role ID no
> >
icts.
The attached patch is rebased against master.
Thanks,
Joe Koshakow
From eee98dd65c3556528803b6ee2cab10e9ece8d871 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 9 Apr 2023 20:37:27 -0400
Subject: [PATCH] Fix interval decode handling of invalid intervals
This patch does three things i
Fri, Jun 23, 2023 at 1:54 PM Nathan Bossart
wrote:
> On Thu, Jun 22, 2023 at 06:39:45PM -0400, Joseph Koshakow wrote:
> > On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart <
> nathandboss...@gmail.com>
> > wrote:
> >> I see that RESET SESSION AUTHORIZATION
> &g
On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart
wrote:
>
>On Wed, Jun 21, 2023 at 04:28:43PM -0400, Joseph Koshakow wrote:
>> + roleTup = SearchSysCache1(AUTHOID,
ObjectIdGetDatum(AuthenticatedUserId));
>> + if (!HeapTupleIsValid(roleTup))
>> +
://www.postgresql.org/docs/15/sql-set-session-authorization.html
From b5f7d42ea325b2be46b7c93e5404792046f1befc Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Thu, 15 Jun 2023 14:53:11 -0400
Subject: [PATCH] Prevent non-superusers from altering session auth
Previously, if a user connected
On Wed, Jun 7, 2023 at 11:36 AM Fujii Masao
wrote:
>
>
>
>On 2023/06/07 23:15, Joseph Koshakow wrote:
>> I think I may have discovered a reason why is_superuser is
>> intentionally undocumented. is_superuser is not updated if a role's
>> superuser a
I think I may have discovered a reason why is_superuser is
intentionally undocumented. is_superuser is not updated if a role's
superuser attribute is changed by another session. Therefore,
is_superuser may show you an incorrect stale value.
Perhaps this can be fixed with a show_hook? Otherwise
Sorry for the multiple consecutive emails. I just came across this
comment that explains the current behavior in restrict_and_check_grant
/*
* Restrict the operation to what we can actually grant or revoke, and
* issue a warning if appropriate. (For REVOKE this isn't quite what the
* spec says
I've been thinking about this some more and reading the SQL99 spec. In
the original thread that added these warnings [0], which was linked
earlier in this thread by Nathan, the following assertion was made:
> After that, you get to the General Rules, which pretty clearly say that
> trying to
On Thu, May 18, 2023 at 7:17 PM Joseph Koshakow wrote:
>
>I looked into this function and that is correct. We fail to find a
>match for the revoked privilege here:
>
>/*
>* Search the ACL for an existing entry for this grantee and grantor. If
>* on
On Wed, May 17, 2023 at 11:48 PM Nathan Bossart
wrote:
>
>The thread for the aforementioned change [0] mentions the standard
quite a
>bit, which might explain the current behavior.
I went through that thread and the quoted parts of the SQL standard. It
seems clear that if a user tries to
Hi Hackers,
I noticed some confusing behavior with REVOKE recently. Normally if
REVOKE fails to revoke anything a warning is printed. For example, see
the following scenario:
```
test=# SELECT current_role;
current_role
--
joe
(1 row)
test=# CREATE ROLE r1;
CREATE ROLE
test=#
On Tue, Apr 11, 2023 at 9:37 AM Fujii Masao
wrote:
>> > Yes, this patch moves the descriptions of is_superuser to
config.sgml
>> > and changes its group to PRESET_OPTIONS.
>>
>> is_superuser feels a little out of place in this file. All of
>> the options here apply to the
b3c5953553bb9fb0b171abc6041e7c7e9ca5b4d
[2]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bcc704b52490492e6bd73c056b3e9644504d
From 4c5641f15e5409ef5973a5f305352018f06da538 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 9 Apr 2023 20:37:27 -0400
Subject: [PATCH]
On Mon, Apr 3, 2023 at 10:47 AM Fujii Masao
wrote:
>Yes, the patch has not been committed yet because of lack of review
comments.
>Do you have any review comments on this patch?
>Or you think it's ready for committer?
I'm not very familiar with this code, so I'm not sure how much my
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 *
>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 improve
think.
With this patch I believe that I've addressed all open comments except
for the discussion around whether we should check just the months field
or all three fields for finiteness. Please let me know if I've missed
something.
Thanks,
Joe Koshakow
From e50d4ca6321c58d216d563f74502356d721c2b4b Mon
On Wed, Mar 29, 2023 at 5:21 PM Bruce Momjian wrote:
>
>On Thu, Mar 2, 2023 at 12:00:43PM -0500, Joseph Koshakow wrote:
>>
>>
>> On Thu, Mar 2, 2023 at 11:53 AM Fujii Masao <
masao.fu...@oss.nttdata.com>
>> wrote:
>> >
>
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
I'll save
that for a future patch.
- Joe Koshakow
From 41fa5de65c757d72331aff6bb626fab76390e9db Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 18 Mar 2023 12:26:28 -0400
Subject: [PATCH 1/2] Move integer helper function to int.h
---
src/backend/utils/adt/dateti
ntactically 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
Subject: [PATCH
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 d
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 variab
Also I removed some dead code from the previous patch.
- Joe Koshakow
From 2ff08d729bca87992514d0651fdb62455e43cd8a Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 10 Dec 2022 18:59:26 -0500
Subject: [PATCH] Remove unknown ISO format, handle dandling units
This commit removes the date
On Sun, Mar 5, 2023 at 12:54 PM Tom Lane wrote:
>
> We do accept this:
>
> => select '12:34'::time;
>time
> --
> 12:34:00
> (1 row)
>
> so that must be going through a different code path, which I didn't
> try to identify yet.
That query will contain a single field of "12:34" with
Attached is a patch for removing the discussed format of date-times.
From f35284762c02ed466496e4e562b5f95a884b5ef1 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 10 Dec 2022 18:59:26 -0500
Subject: [PATCH] Remove unknown ISO format, handle dandling units
This commit removes the date
On Sat, Mar 4, 2023 at 4:05 PM Tom Lane wrote:
>
>I started to look at this, and soon noticed that while we have test
cases
>matching this sort of date input, there is no documentation for it.
The
>code claims it's an "ISO" (presumably ISO 8601) format, and maybe it is
>because it
oshakow
From 64a71ed287aa9611c22eaa6e2cbb7e080d93be79 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 11 Dec 2022 16:08:43 -0500
Subject: [PATCH] Handle extraneous fields in date-time input
DecodeDateTime sometimest allowed extraneous fields to be included with
reserved keywords. For examp
On Sat, Mar 4, 2023 at 1:56 PM Tom Lane wrote:
>
>I think we should tread very carefully about disallowing inputs that
>have been considered acceptable for 25 years. I agree with disallowing
>numeric fields along with 'epoch' and 'infinity', but for example
>this seems perfectly
case.
Any thoughts?
- Joe Koshakow
From 78d8f39db8df68502369ffd9edd6f6e38f4dadb8 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 11 Dec 2022 16:08:43 -0500
Subject: [PATCH] Handle extraneous fields in date-time input
DecodeDateTime sometimest allowed extraneous fields to be included
On Sat, Mar 4, 2023 at 11:23 AM Keisuke Kuroda
wrote:
>
>Good catch.
>Of the reserved words that are special values of type Date/Time,
>'now', 'today', 'tomorrow', 'yesterday', and 'allballs',
>I get an error even before applying the patch.
Thanks for pointing this out. After
On Thu, Mar 2, 2023 at 11:53 AM Fujii Masao
wrote:
>
>On 2022/09/14 14:27, bt22kawamotok wrote:
>> I update patch to reflect master update.
>
>Thanks for updating the patch!
>
>+
>+Shows whether the current user is a superuser or not.
>+
>
>How
it's rebased?
There hasn't really been a review of this patch yet. It's just been
mostly me talking to myself in this thread, and a couple of
contributions from jian.
- Joe Koshakow
From 1b35e2b96bcf69431bbd8720523163de10cf Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17 Dec 2022 14
On Fri, Feb 24, 2023 at 1:31 PM Nathan Bossart
wrote:
> You might be interested in
>
>https://commitfest.postgresql.org/42/4145/
Ah, perfect. In that case ignore my patch!
- Joe Koshakow
denied to create database
It's not a huge deal, but it's easy enough to fix that I thought I'd
generate a patch (attached). Let me know if people think that it's
worth merging.
- Joe Koshakow
From 3ab31bc755043973ce56ee620ad99b5789d12111 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date:
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
timestamp subtraction.
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
From 23868228ad2c0be57408b38db76bced85ab83cb1 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17
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:
>> &
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 on
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
>
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"
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: Josep
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
Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 17 Dec 2022 14:21:26 -0500
Subject: [PATCH] This is WIP.
TODOs
1. Various TODOs in code.
2. Correctly implement interval_part for infinite intervals.
3. Test consolidation.
4. Should we just use the months field to test for infinity?
Ashu
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
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
>
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
cleanup, remove TODOs.
Attached is my most recent patch.
- Joe Koshakow
From 380cde4061afd6eed4cde938a4c668a2c96bb58f 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 supported
1. Accepts '+/-infinity
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
> er
s, we do change the sign of infinity.
- Joe Koshakow
From 4c1be4e2aa7abd56967fdce14b100715f3a63fee 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 supported
1. Accepts '+/-infinity' as a valid string input for i
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.
On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow wrote:
>
> I just found another class of this bug that the submitted patch does
> not fix. If the units are at the beginning of the string, then they are
> also ignored. For example, `date 'm d y2020m11d3'` is also valid. I
> thi
I just found another class of this bug that the submitted patch does
not fix. If the units are at the beginning of the string, then they are
also ignored. For example, `date 'm d y2020m11d3'` is also valid. I
think the fix here is to check and make sure that ptype is 0 before
reassigning the value
fb4c161afff08b926eea12d8689a148e99cbdb5c Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 11 Dec 2022 16:08:43 -0500
Subject: [PATCH] Handle extraneous fields in date-time input
DecodeDateTime sometimest allowed extraneous fields to be included with
reserved keywords. For example `date '1995-08-06
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
1 - 100 of 108 matches
Mail list logo
