Sorry about that and thanks for the fix!
- Joe Koshakow
Hi I am working with Aidar to give a review and I am also a beginner
reviewer.
> From 813e5ec0da4c65970b4b1ce2ec2918e4652da9ab Mon Sep 17 00:00:00 2001
> From: Nazir Bilal Yavuz
> Date: Fri, 20 Dec 2024 14:06:47 +0300
> Subject: [PATCH v1 1/2] Add pg_buffercache_evict_all() function for
testing
>
On Sat, Mar 8, 2025 at 4:28 PM Joseph Koshakow wrote:
>
> The assert was introduced commit f16241
>
> So if I understand correctly, at the time the assert was added, we in
> fact did not support UPDATE of INSERT ON CONFLICT for a partitioned
> table. However, since then we&#x
I don't fully understand why an error is needed though. This specific
case will return false which will signal the caller to retry the
insert. Just as an experiment I tried deleting the assert (attached
patch) and running your test. Everything behaved as expected and
nothing blew up. It also seems t
is
happy. Also I agree, we should close the commitfest entry.
Thanks,
Joseph Koshakow
think it's worth pursuing.
Thanks,
Joseph Koshakow
From c046465d4532e9b9086e0aadd13526e2a284b072 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 1 Dec 2024 14:55:35 -0500
Subject: [PATCH v1] Fix date_trunc units for infinite intervals
Previously, if an infinite value was passe
ors
test=# SELECT to_timestamp('2147483647,999', 'Y,YYY');
ERROR: invalid input string for "Y,YYY"
test=# SELECT to_date('-2147483648', 'CC');
ERROR: date out of range: "-2147483648"
So, it might be worth committing only his changes before moving on.
Thanks,
Joseph Koshakow
ced another potential issue with next_pow2_int. The
implementation is in dynahash.c and is as follows
/* calculate first power of 2 >= num, bounded to what will fit in an
int */
static int
next_pow2_int(long num)
{
if (num > INT_MAX / 2)
num = INT_MAX / 2;
ing on -fwrapv here. godbolt.org indicates that
> it produces roughly the same code, too.
>
> diff --git a/src/backend/nodes/bitmapset.c b/src/backend/nodes/bitmapset.c
> index cd05c642b0..d37a997c0e 100644
> --- a/src/backend/nodes/bitmapset.c
> +++ b/src/backend/nodes/bi
nd godbolt.org [0] seems to indicate that it might produce better code,
> too (at least to my eye).
This updated version LGTM, I agree it's a good use of pg_abs_s32().
Thanks,
Joseph Koshakow
+ 1;
return i64_abs(a);
}
Thanks,
Joseph Koshakow
error? If so, I'm not sure I understand the
reasoning. -2147483648 is an allowed integer, it's the minimum allowed
value for integers.
test=# SELECT (-2147483648)::integer;
int4
-----
-2147483648
(1 row)
Thanks,
Joseph Koshakow
ue is
> returned?
I've added a comment to the top of the file where we describe the
return values of the other functions.
I also updated the implementations of the pg_abs_sX() functions to
something a bit simpler. This was based on feedback in another patch
[0], and more closely matches similar lo
he fix here is to just convert `nbuckets` to a `long`. I
plan on checking if that's feasible.
I also found this commit [0] that increased the max of `nbuckets` from
`INT_MAX / BLCKSZ` to `INT_MAX / 2`, which introduced the possibility
of this overflow. So I plan on re
rom
the negative case because I think it was unnecessary, but happy to add
it back in if I missed something.
Thanks for the review!
Thanks,
Joseph Koshakow
[0]
https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Integer-Overflow-Basics.html
From 1811b94ba4c08a0de972e8ded4892
On Sat, Jul 27, 2024 at 8:00 PM David Rowley wrote:
>
> On Sun, 28 Jul 2024 at 11:06, Joseph Koshakow wrote:
>> > + uint64 usize = size < 0 ? (uint64) (-size) : (uint64) size;
>>
>> I think that the explicit test for PG_INT64_MIN is still required. If
>>
On Sat, Jul 27, 2024 at 6:28 PM David Rowley wrote:
>
> On Sun, 28 Jul 2024 at 07:18, Joseph Koshakow wrote:
>> Attached is a patch that resolves an overflow in pg_size_pretty() that
>> resulted in unexpected behavior when PG_INT64_MIN was passed in as an
>> argument.
&g
On Sat, Jul 27, 2024 at 3:18 PM Joseph Koshakow wrote:
>
> `SELECT -9223372036854775808::bigint` results in an out of range error,
> even though `-9223372036854775808` can fit in a `bigint` and
> `SELECT pg_typeof(-9223372036854775808)` returns `bigint`. That's why
> th
;s why
the `::bigint` cast is omitted from my test.
[0]
https://www.postgresql.org/message-id/flat/caavxfhdbpoyegs7s+xf4iaw0-cgiq25jpydwbqqqvltle_t...@mail.gmail.com
Thanks,
Joseph Koshakow
From 6ec885412f2e0f3a3e019ec1906901e39c6d517a Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 27 Jul
ch that fixes the to_date() overflow. Patches 1
through 3 remain unchanged.
Thanks for the contribution Mattew!
On Tue, Jul 23, 2024 at 2:14 AM jian he wrote:
>
> On Tue, Jul 23, 2024 at 6:56 AM Joseph Koshakow wrote:
>>
>> The specific bug that this patch fixes is preventing the
ng the following
statement:
# INSERT INTO arroverflowtest(i[-2147483648:2147483647]) VALUES ('{1}');
So we may want to add that test back in.
Thanks,
Joseph Koshakow
On Mon, Jul 22, 2024 at 11:17 AM Nathan Bossart
wrote:
> On Fri, Jul 19, 2024 at 07:32:18PM -0400, Joseph Koshakow wrote:
>> On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart
>> wrote:
>>> +/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
>>> +
Since the patches have been renumbered, here's an overview of their
status:
- 0001 is reviewed and waiting for v18.
- 0002 is under review and a bug fix.
- 0003 needs review.
Thanks,
Joseph Koshakow
From 6996c17b06d4b7c98130e5c70c368d08ea1ccc80 Mon Sep 17 00:00:00 2001
From: Joseph Koshako
rray size exceeds the maximum allowed (134217727)
As a reminder:
- 0001 is reviewed.
- 0002 is reviewed and a bug fix.
- 0003 is currently under review and a bug fix.
- 0004 needs a review.
Thanks,
Joe Koshakow
From 6c47deeb39eb352d7888c9490613dcf18aee198b Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
On Tue, Jul 16, 2024 at 11:17 PM Nathan Bossart
wrote:
> I've attached an editorialized version of 0002 based on my thoughts above.
Looks great, thanks!
Thanks,
Joe Koshakow
On Tue, Jul 16, 2024 at 1:57 PM Nathan Bossart
wrote:
>>
>>On Mon, Jul 15, 2024 at 07:55:22PM -0400, Joseph Koshakow wrote:
>> On Mon, Jul 15, 2024 at 11:31 AM Nathan Bossart
>> wrote:
>>>I'm curious why you aren't using float8_mul/float8_div he
integer, but there's multiple functions that
divide cash by an integer. I've added a "cash_div_int64" in the updated
patch.
The other patches, 0001, 0003, and 0004 are unchanged but have their
version number incremented.
Thanks,
Joe Koshakow
From 018d952a44d51fb9e0a186003556aebb69
On Fri, Jul 12, 2024 at 12:49 PM Nathan Bossart
wrote:
> On Sat, Jul 06, 2024 at 07:04:38PM -0400, Joseph Koshakow wrote:
>> I've added another patch, 0004, to resolve the jsonb wrap-arounds.
>>
>> The other patches, 0001, 0002, and 0003 are unchanged but have their
>
On Mon, Jul 1, 2024 at 11:45 AM Laurenz Albe
wrote:
> I asked them for a statement, and they were nice enough to write up
> https://postgr.es/m/e89e8dd9-7143-4db8-ac19-b2951cb0c0da%40gmail.com
> They have a workaround, so the patch is not absolutely necessary for them.
It sounds like the issue
s=0,
op_type=2) at jsonfuncs.c:5407
> 5407if (-idx > nelems)
> (gdb) p idx
> $1 = -2147483648
I've added another patch, 0004, to resolve the jsonb wrap-arounds.
The other patches, 0001, 0002, and 0003 are unchanged but have their
version number incremented.
is reviewed and waiting for v18 and a committer.
0002 and 0003 are unreviewed. So, I'm going to mark this as waiting for
a reviewer.
Thanks,
Joe Koshakow
From f3747da14c887f97e50d9a3104881cbd3d5f60de Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 8 Jun 2024 22:16:46 -0400
Subject
On Sat, Jun 22, 2024 at 6:23 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> except invoker and triggerer are the same entity
Maybe "executor" would have been a better term than 'invoker". In this
specific example they are not the same entity. The trigger is
triggered and queued by on
On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe
wrote:
>Like you, I was surprised by the current behavior. There is a design
>principle that PostgreSQL tries to follow, called the "Principle of
>least astonishment". Things should behave like a moderately skilled
>user would expect
On Thu, Jun 13, 2024 at 10:56 PM Joseph Koshakow wrote:
On Thu, Jun 13, 2024 at 10:48 PM Joseph Koshakow
wrote:
>I've attached
>v4-0002-Handle-overflow-in-money-arithmetic.patch which adds some
>overflow checks and tests. I didn't address the f
On Thu, Jun 13, 2024 at 10:48 PM Joseph Koshakow wrote:
>I've attached
>v4-0002-Handle-overflow-in-money-arithmetic.patch which adds some
>overflow checks and tests. I didn't address the float multiplication
>because I didn't see any helper method
e whole iceberg too.
+1
Thanks,
Joe Koshakow
From 31e8de30a82e60151848439143169e562bc848a3 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 8 Jun 2024 22:16:46 -0400
Subject: [PATCH 1/2] Remove dependence on integer wrapping
This commit updates various parts of the code to no longer rely on
i
mp.c...
The attached patch has updated this file too. For some reason I was
under the impression that I should leave the ecpg/ files alone, though
I can't remember why.
Thanks,
Joe Koshakow
From adcf89561cec31499754a7c04da50c408a12724a Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sa
tip of the iceberg.
Agreed.
> Is there any chance of using static
> analysis to find all the places of concern?
I'm not personally familiar with any static analysis tools, but I can
try and do some research. Andres had previously suggested SQLSmith. I
think any kind of fuzz testing wi
,
Joe Koshakow
[0]
https://www.postgresql.org/message-id/20240213191401.jjhsic7et4tiahjs%40awork3.anarazel.de
From 319bc904858ad8fbcc687a923733defd3358c7b9 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sat, 8 Jun 2024 22:16:46 -0400
Subject: [PATCH] Remove dependence on integer wrapping
This commit upd
On Sat, Jun 8, 2024 at 10:13 PM Isaac Morland
wrote:
> Speaking as a table owner, when I set a trigger on it, I expect that when
the specified actions occur my trigger will fire and will do what I
specify, without regard to the execution environment of the caller
(search_path in particular); and
On Sat, Jun 8, 2024 at 5:36 PM Joseph Koshakow wrote:
>Additionally, I applied your patch to master and re-ran the example and
>didn't notice any behavior change.
>
>test=# CREATE TABLE tab (i integer);
>CREATE TABLE
>test=# CREATE FUNCTION
Hi,
I see that this patch is marked as ready for review, so I thought I
would attempt to review it. This is my first review, so please take it
with a grain of salt.
> So a deferred constraint trigger does not run with the same security
context
> as an immediate trigger.
It sounds like the crux o
Hi Andres,
Sorry for such a late reply.
On Tue, Feb 13, 2024 at 2:14 PM Andres Freund wrote:
> Random, mildly related thought: I wonder if it's time to, again, look at
> enabling -ftrapv in assert enabled builds.I had looked at that a few years
> back, and fixed a number of instances, but not a
n the previous 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: [
ached 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 conflic
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
ch 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: S
to
>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 h
&& 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 nerv
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
698c7da Mon Sep 17 00:00: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
poi
imes reports an incorrect 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 2e1689b5fe384d675043beb9df
ession_authorization.
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
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
follo
alog 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
>
s a rebase for the CI, too, but there are
> no conflicts.
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 handli
shakow
On 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 AUTHORIZATI
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))
>> +
5sFzqEJQ%40mail.gmail.com
[1] https://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
Previo
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
>> superu
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 it'
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 to
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 grant
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
>* one ex
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=# CREAT
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 en
?p=postgresql.git;a=commit;h=5b3c5953553bb9fb0b171abc6041e7c7e9ca5b4d
[2]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bcc704b52490492e6bd73c4444056b3e9644504d
From 4c5641f15e5409ef5973a5f305352018f06da538 Mon Sep 17 00:00:00 2001
From: Joseph Koshakow
Date: Sun, 9 Apr 2023 20:37:27
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
r
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 c
>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 im
patches. Let me know what you 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 e50d
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 that
number 7, but 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/back
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
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 v
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 ft
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
Joe Koshakow
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
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 u
fault 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 taki
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 abo
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,
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
ermission 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
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 th
handling of infinite 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 Kos
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
1 - 100 of 151 matches
Mail list logo
