On Wed, 3 Sept 2025 at 07:47, Michael Paquier wrote:
>
> The same error message is repeated twice. How about using some gotos
> and one single ereport instead of two? The same can be said for
> numeric_div_safe() and numeric_mod_safe(), for the division-by-0
> messages.
In numeric_div_safe() an
On Mon, 1 Sept 2025 at 10:36, Amul Sul wrote:
>
> I believe we should update all *_opt_error functions to use the new
> soft error reporting infrastructure instead of boolean flags -- did
> the same in the attached patch. I am not sure if this patch should be
> part of that thread[1]. It's a signi
On Sun, 24 Aug 2025 at 18:34, Yugo Nagata wrote:
>
> I confirmed this issue by executing the following query concurrently
> in three transactions. (With only two transactions, the issue does not occur.)
Yes, I think 3 transactions are required to reproduce this (2 separate
concurrent updates).
>
On Mon, 25 Aug 2025 at 12:42, Damien Clochard wrote:
>
> Note that former random function variants are documented in
> func/func-math.sgml but it felt more logical to document the new
> variants in func-datetime.sgml. As a result the random variants would be
> documented in 2 separate sections of
On Thu, 21 Aug 2025 at 04:41, Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, July 11, 2025 3:09 PM Dean Rasheed
> wrote:
> >
> > In HEAD, it would be OK to change the signature of
> > CheckValidResultRel() and pass it an onConflictAction argument to fix
> > the ON
On Mon, 11 Aug 2025 at 12:25, Etsuro Fujita wrote:
>
> /*
> * Other information needed by child result relations
> *
> * RootResultRelInfo gives the target relation mentioned in the query.
> * Used as the root for tuple routing and/or transition capture.
> *
> * P
On Mon, 4 Aug 2025 at 15:18, Tender Wang wrote:
>
> Dean Rasheed 于2025年8月4日周一 22:10写道：
>>
>> While looking at create_index.sql, I noticed the following:
>>
>> which isn't testing what it claims to test because there's a typo in
>> the table name. P
atch: 2206ms
>
> Query 2:
> HEAD: 3394ms
> Patch: 2514ms
Thanks for testing.
On Fri, 18 Jul 2025 at 07:47, John Naylor wrote:
>
> On Thu, Jul 17, 2025 at 2:30 PM Dean Rasheed wrote:
> >
> > BTW, my other motivation for doing this was to simplify the numeric
> &
a typo in
the table name. Patch attached.
Regards,
Dean
From eb98319fac5bb767b5d88b0efeb1b2414b78b78c Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Mon, 4 Aug 2025 15:02:40 +0100
Subject: [PATCH v1] Fix typo in create_index.sql.
Introduced by 578b229718e.
Author: Dean Rasheed
Discuss
Rebased version attached, following 904f6a593a0.
Regards,
Dean
From a47423cc29abc8dc197fb895b55aace66d9da885 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Fri, 25 Jul 2025 08:57:03 +0100
Subject: [PATCH v4] Allow EXCLUDED in RETURNING list of INSERT ON CONFLICT DO
UPDATE.
This allows an
On Fri, 11 Jul 2025 at 23:22, Paul Jungwirth
wrote:
>
> On 7/11/25 11:50, Rustam ALLAKOV wrote:
> > Hi Paul,
> > Thanks for this patch!
> > Lilian and I have reviewed your patches.
>
> Thank you for the review! I've attached new patches addressing your feedback.
>
I agree that additional testing
On Wed, 16 Jul 2025 at 19:23, Dean Rasheed wrote:
>
> On 64-bit Linux with gcc 14.2 and native int128 support disabled I got
> the following results:
>
> Query 1:
> HEAD: 1404.096 ms
> Patch: 992.818 ms
>
> Query 2:
> HEAD: 1498.949 ms
> Patch: 935.6
On Wed, 16 Jul 2025 at 22:22, Nathan Bossart wrote:
>
> Okay, here is a new version of the patch.
>
LGTM.
Regards,
Dean
On Wed, 16 Jul 2025 at 18:26, Nathan Bossart wrote:
>
> On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote:
> > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote:
> >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston
> >> > The pg_overexplain exte
On Wed, 16 Jul 2025 at 10:02, John Naylor wrote:
>
> On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed wrote:
> > 0005 is the main patch. It adds a few more functions to int128.h and
> > uses them in numeric.c to allow various functions (mainly aggregate
> > functions)
On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote:
>
> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston
> > The pg_overexplain extends EXPLAIN with new options that provide...
> > Suggest instead:
> > The pg_overexplain module provides EXPLAIN with new options intended to
> > assist with debuggin
On Tue, 15 Jul 2025 at 04:49, Robert Treat wrote:
>
> On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed wrote:
> >
> > But it's completely trivial to emulate random(min_date, max_date), just by
> > doing
> >
> > min_date + random(0, max_date - min_date)
On Mon, 14 Jul 2025 at 22:07, Dean Rasheed wrote:
>
> > warning: format ‘%lX’ expects argument of type ‘long unsigned int’,
> > but argument 4 has type ‘int32’ {aka ‘int’} [-Wformat=]
> >
> v4 attached.
v5 attached, fixing some more printf-related compiler warnings, thi
yes, thanks for pointing that out.
(The cfbot reports the same warnings, but you have to scroll through a
lot of output to see them. It would be nice if the commitfest app had
an indicator to show if there were any compiler warnings.)
v4 attached.
Regards,
Dean
From 5d1523cf58c58b90a8e4acc109fcbc32
On Sat, 12 Jul 2025 at 16:15, Greg Sabino Mullane wrote:
>
> I like the idea, especially the date variant. Unlike Tom, I'm not
> particularly concerned about breakage of existing scripts, as
> most already are working just fine with raw numbers and I don't see this
> patch breaking them.
>
> In
On Tue, 8 Jul 2025 at 15:26, Aleksander Alekseev
wrote:
>
> The proposed function seems to do two things at a time - generating
> random values and transforming them into an array of desired
> dimensions. Generally we try to avoid such interfaces. Can you think
> of something like array_transform(
On Tue, 8 Jul 2025 at 09:51, Dean Rasheed wrote:
>
> Answering my own question, INSERT ... ON CONFLICT DO UPDATE does have
> the same problem as MERGE. To reproduce the error, all you need to do
> is create the unique index it needs *after* creating the publication
The other questio
On Thu, 10 Jul 2025 at 15:06, Dean Rasheed wrote:
>
> > Yes, perhaps we should convert src/tools/testint128.c into a new test
> > extension, src/test/modules/test_int128
>
> Here's an update doing that (in 0001). 0002-0005 are unchanged.
v3 attached, fixing a couple
On Wed, 9 Jul 2025 at 22:31, Dean Rasheed wrote:
>
> On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
> >
> > I think we should wire this up to the buildsystem and our testsuite...
> > Having
> > testcode that is not run automatically may be helpful while origi
On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
>
> I think we should wire this up to the buildsystem and our testsuite... Having
> testcode that is not run automatically may be helpful while originally
> developing something, but it doesn't do anything to detect portability issues
> or regress
On Wed, 9 Jul 2025 at 07:41, John Naylor wrote:
>
> Hi Dean, I went to take a look at this and got stuck at building the
> test file. The usual pointing gcc to the src and build include
> directories didn't cut it. How did you get it to work?
>
Yes, it wasn't immediately obvious how to do it. I f
On Mon, 28 Apr 2025 at 16:02, Khan, Tanzeel wrote:
>
> A comment in relcache.c mentions that RelationBuildRowSecurity
> adds a default-deny policy when no policy exists on table. This
> does not seem to be the case. The default deny policy is added
> later on, inside get_row_security_policies(). A
On Mon, 7 Jul 2025 at 18:17, Dean Rasheed wrote:
>
> This makes me wonder though, does INSERT ... ON CONFLICT DO UPDATE
> have the same problem as MERGE?
>
Answering my own question, INSERT ... ON CONFLICT DO UPDATE does have
the same problem as MERGE. To reproduce the error, all yo
On Mon, 7 Jul 2025 at 11:38, Jim Jones wrote:
>
> I'm wondering if the current behaviour with DEFAULT columns should be
> mentioned in the docs.
Hmm, perhaps. On the INSERT page, under "conflict_action", we currently say
Note that the effects of all per-row BEFORE INSERT triggers are
ref
On Mon, 14 Apr 2025 at 05:40, Ashutosh Bapat
wrote:
>
> I was wondering whether we should mention MERGE somewhere in the error
> message like "cannot merge into table ...". But the error message is
> reported depending upon the actual operation being performed and
> whether it's being published by
On Sat, 5 Jul 2025 at 08:32, Vik Fearing wrote:
>
> On 30/06/2025 17:04, jian he wrote:
>
> reasons for adding array_random is:
> 1. This is better than array_fill. This can fill random and constant
> values (random, min and max the same).
> 2. Building a multi-dimensional PL/pgSQL function equiv
On Fri, 4 Jul 2025 at 13:07, Kirill Panin wrote:
>
> Thanks for your response.
> Do you think it makes sense to disallow cube+cube operations and only
> allow cube+point or point+point instead? Dot and cross products would be
> similarly only defined for point+point if someone were to implement th
On Thu, 15 May 2025 at 16:16, Kirill Panin wrote:
>
> Hi hackers!
>
> The "cube" extention is frequently used for vectors, but the current
> implementation lacks support for binary operators, such as +, -, *, /.
> The attached (fairly trivial) patch adds support for these with the
> required docum
On Sat, 21 Jun 2025 at 22:21, Tom Lane wrote:
>
> The attached patch does what was discussed in the pgsql-docs
> thread at [1], namely change the four-argument variants of
> width_bucket() to allow their first argument to be NaN,
> treating that value as larger than any non-NaN.
>
LGTM.
I note t
On Sun, 13 Apr 2025 at 17:40, Abhishek Chanda wrote:
>
> Thanks for the feedback, attached an updated patch that changes most
> of those "Did not find" messages to empty tables. I did not change two
> sets, listDbRoleSettings and listTables both have comments describing
> that these are deliberate
On Tue, 24 Jun 2025 at 19:49, Dean Rasheed wrote:
>
> The attached patch allows EXCLUDED values to appear in the RETURNING
> list of INSERT ... ON CONFLICT DO UPDATE.
>
> I still have a lot more testing to do, and docs to update, but so far
> the results look promising. I'
On Thu, 26 Jun 2025 at 04:04, Robert Treat wrote:
>
> At first look this seems right, modulo some typos
Oops, yes that was careless. Thanks for checking. I've fixed those and
pushed it.
Regards,
Dean
On Wed, 25 Jun 2025 at 15:53, Nathan Bossart wrote:
>
> Seems reasonable to me.
>
Pushed. Thanks for looking.
Regards,
Dean
Looking at the docs for MERGE, I realised that the "Synopsis" is not
indented consistently with other pages -- the convention on almost
every other page seems to be to indent continuation lines and options
by 4 spaces. So I think we should do the same for MERGE, as in the
attached.
Regards,
Dean
d
On Thu, 16 Jan 2025 at 15:28, Dean Rasheed wrote:
>
> I went over this again in detail and didn't find any problems, so I
> have committed it. Thanks for all the review comments.
>
Looking at the doc pages for UPDATE and MERGE, I realise that I missed
a paragraph in the &quo
On Mon, 12 May 2025 at 19:33, Andreas Karlsson wrote:
>
> I have fixed that one and some other issues locally and will submit a
> new version in a while after I have added more tests because you are
> very correct in that a big issue with my last version of the patch was
> the big lack of tests an
7e25d53053b342d05767 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Mon, 23 Jun 2025 17:20:02 +0100
Subject: [PATCH v1] Allow EXCLUDED in RETURNING list of INSERT ON CONFLICT DO
UPDATE.
TODO:
* More testing
* Docs
---
src/backend/executor/execExpr.c | 44 +--
src/backen
edup in a couple of simple queries using
those aggregates.
Regards,
Dean
From a2f787a5d38bc3ca44c21d5c1c90a7cf615b68e2 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Sat, 21 Jun 2025 18:09:15 +0100
Subject: [PATCH v1 4/5] Simplify non-native 64x64-bit multiplication in
int128.h.
In i
On Tue, 17 Jun 2025 at 13:56, jian he wrote:
>
> On Tue, Jun 17, 2025 at 7:42 PM Peter Eisentraut wrote:
> >
> > However, I see your point that it contrasts with the attidentity code
> > just above.
> >
> > Perhaps a way to resolve this would be to rewrite the comment something
> > like:
> >
> >
On Tue, 17 Jun 2025 at 06:27, Peter Eisentraut wrote:
>
> On 10.04.25 11:46, Amit Langote wrote:
> >
> > On Thu, Apr 10, 2025 at 5:58 PM jian he wrote:
> >>
> >> in function, rewriteTargetListIU we have:
> >>
> >> /*
> >> * Can only insert DEFAULT into generated columns
On Wed, 28 May 2025 at 11:37, Tender Wang wrote:
>
> Dean Rasheed 于2025年5月28日周三 18:26写道：
>>
>> Unless there are any further comments, I plan to commit it in a day or so.
>
> I don't have any other comments. It looks good for me.
>
Thanks for looking. I have committed this now.
Regards,
Dean
On Mon, 26 May 2025 at 12:50, Tender Wang wrote:
>
>> > "it is possible for the parent to be excluded from the
>> > plan and so all of the entries in the resultRelInfo array may be for
>> > different relations than rootResultRelInfo."
>> >
>> > I didn't fully understand the above sentence. Can y
644
index 619592b..536d7c0
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -2905,13 +2905,22 @@ Add ARM Neon and SVE CPU intrinsics for
-Improve the speed of multiplication (Joel Jacobson, Dean Rasheed)
+Improve the speed of numeric multiplication and division (Joel Jacobson, Dean Rasheed)
+§
+§
§
+§
On Mon, 26 May 2025 at 10:39, Tender Wang wrote:
>
> jian he 于2025年5月26日周一 17:30写道：
>>
>> + Relation rootRelation = rootRelInfo->ri_RelationDesc;
>> + Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc;
>> + int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex;
>>
>> fir
On Mon, 26 May 2025 at 07:46, Tender Wang wrote:
>
> Hi Dean,
>
> "it is possible for the parent to be excluded from the
> plan and so all of the entries in the resultRelInfo array may be for
> different relations than rootResultRelInfo."
>
> I didn't fully understand the above sentence. Can you
ingList, but I don't think it really makes sense
to do it there. The patch intentionally only does it for a MERGE into
an inherited table when there are INSERT actions, and this also allows
the new code to be more consistent with ExecInitPartitionInfo().
Regards,
Dean
From 1d20f593cbc3f4546
On Sun, 25 May 2025 at 13:41, Dean Rasheed wrote:
>
> On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
> >
> > For a partitioned table, we must pass rootResultRelInfo to ExecInsert(). I
> > added the check before calling ExecInsert()
> > If it is a partitio
On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
>
> For a partitioned table, we must pass rootResultRelInfo to ExecInsert(). I
> added the check before calling ExecInsert()
> If it is a partitioned table, we continue to pass rootResultRelInfo.
> Otherwise, we pass resultRelInfo.
> Please see th
On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
>
> On 4/4/25 09:37, Richard Guo wrote:
> > On Wed, Apr 2, 2025 at 10:26 PM Richard Guo wrote:
> > With more exposure to the changes in ChangeVarNodes(), I have some
> > more concerns. As I understand it, ChangeVarNodes() is designed to
> > upd
> > On 3/4/25 10:24 AM, Andreas Karlsson wrote:
> > Rebased the patch to add support for OLD.* and NEW.*.
>
I took a closer look at this, and I have a number of comments:
* The changes for RLS look correct. However, in
get_row_security_policies(), it's not necessary to add
WCO_RLS_UPDATE_CHECK ch
rom 0001, and fixes
the paragraph mentioned above.
Regards,
Dean
From c2c49cd10f001a5ee7a2d52083b2fcd3232fc53e Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Thu, 27 Mar 2025 14:08:09 +
Subject: [PATCH v1 1/2] New RLS tests to test policies applied by command
type.
The existing RLS tests f
On Tue, 25 Mar 2025 at 05:01, Alexandra Wang
wrote:
>
> I reviewed the patch and it looks good to me. I’ve run some tests, and
> everything works as expected.
Thanks for the careful review and testing.
> Raising an error instead of silently returning Inf for invalid inputs
> like zero, negative
> On 3/4/25 10:24 AM, Andreas Karlsson wrote:
> Rebased the patch to add support for OLD.* and NEW.*.
create table t (key int primary key, val text);
insert into t values (1, 'old');
insert into t values (1, 'new') on conflict (key) do select for update
returning old.*, new.*;
key | val | key
On Wed, 12 Mar 2025 at 07:45, Richard Guo wrote:
>
> I refined the comment in v2 and ended up with:
>
> * This analysis could be tighter: in particular, a non-strict
> * construct hidden within a lower-level PlaceHolderVar is not
> * reason to add another PHV. But for now it doe
On Mon, 10 Mar 2025 at 13:05, Richard Guo wrote:
>
> Attached are the patches.
>
This looks good to me. I did some more testing, and I wasn't able to break it.
Some minor nitpicks:
These 2 comment changes from 0002 could be made part of 0001:
1). In pull_up_simple_subquery(), removing the word
On Sat, 1 Mar 2025 at 11:30, Dean Rasheed wrote:
>
> With those updates, I think this is ready for commit, which I'll do in
> a day or two, if there are no further comments.
>
Committed.
Regards,
Dean
On Wed, 5 Mar 2025 at 09:09, Richard Guo wrote:
>
> I noticed the adjacent code that sets wrap_non_vars to true if we
> are considering an appendrel child subquery, and I doubt this is
> necessary.
>
> /*
> * If we are dealing with an appendrel member then anything that's not a
> * simple Var
On Thu, 14 Nov 2024 at 22:35, Dean Rasheed wrote:
>
> On Thu, 14 Nov 2024 at 16:28, Dmitry Koval wrote:
> >
> > >SELECT gamma(float8 '1e-320');
> > ERROR: value out of range: overflow
> >
> > >SELECT gamma(float8 '0');
> >
gards,
Dean
From 5c0572a0930067f7244606384542d670cd1e4aa6 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Sat, 1 Mar 2025 10:49:24 +
Subject: [PATCH v10] Allow casting between bytea and integer types.
This allows smallint, integer, and bigint values to be cast to and
from bytea. The bytea valu
On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote:
>
> Here are the updated patches with revised comments and some tweaks to
> the commit messages. I plan to push them in one or two days.
>
LGTM.
Regards,
Dean
On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote:
>
> Yeah, it's annoying that the two replace_rte_variables callbacks have
> so much code duplication. I think it's a win to make them share
> common code. What do you think about making this refactor a separate
> patch, as it doesn't seem directly
On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
>
> One thing I don't like about this is that it's introducing more code
> duplication between pullup_replace_vars() and
> ReplaceVarsFromTargetList(). Those already had a lot of code in common
> before RETURNING OLD/N
On Tue, 18 Feb 2025 at 13:12, Richard Guo wrote:
>
> > It seems to me that, for a relation in the rangetable that has virtual
> > generated columns, we can consider it a subquery to some extent. For
> > instance, suppose we have a query:
> >
> > select ... from ... join t on ...;
> >
> > and supp
On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
>
> On 13.02.25 14:06, jian he wrote:
> > I didn't solve the out join semantic issue.
> > i am wondering, can we do the virtual generated column expansion in
> > the rewrite stage as is,
> > and wrap the expressions in PHVs if the virtual gener
On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote:
>
> Yeah, this is quite contorted. I have renamed it like you suggested.
I looked over this again and I think the patch is in good shape to be committed.
One thought that occurred to me was whether it would be better for the
psql describe out
On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut wrote:
>
> Here is an updated patch that integrates the above changes and also
> makes some adjustments now that the logical replication configuration
> questions are resolved. I think this is complete now.
>
In struct ResultRelInfo, the following f
On Thu, 23 Jan 2025 at 14:30, Aleksander Alekseev
wrote:
>
> Hi Peter,
>
> > These casts appear to use a particular endianness, but they don't
> > document which one, and there is no explanation anywhere why that one is
> > the right one.
>
> Right, I choose network order / big-endian. I agree tha
On Tue, 14 Jan 2025 at 13:25, Aleksander Alekseev
wrote:
>
> Thanks. I agree that the proposed error messages look nicer than the
> one I used in v6. Here is the corrected patch.
>
This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
ERRCODE_INVALID_PARAMETER_VALUE, for consistency wit
On Fri, 17 Jan 2025 at 02:24, Richard Guo wrote:
>
> It seems that adding ParseNamespaceItems for the OLD or NEW aliases
> may confuse scanNameSpaceForRelid() when searching the table namespace
> for a relation item. Since they contain the same RTE,
> scanNameSpaceForRelid() might mistakenly dete
On Wed, 8 Jan 2025 at 09:38, Dean Rasheed wrote:
>
> OK, done.
>
> I also noticed that I had failed to use quote_identifier() in
> ruleutils.c for the new WITH aliases, so I've fixed that and adjusted
> a couple of the test cases to test that.
>
I went over this again
On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut wrote:
>
> Here is a new patch with that fixed and also a few
> tweaks suggested by Jian.
>
I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
that I would check how it works together with this patch. The good
news is that AFAICS ev
On Thu, 9 Jan 2025 at 03:18, Greg Sabino Mullane wrote:
>
> On Wed, Jan 8, 2025 at 8:44 AM Dean Rasheed wrote:
>>
>> Attached is a more complete patch
>
> +1, looks good
>
Thanks for looking. I've pushed this now.
(I realised that I had missed \lo_list, so I a
On Tue, 14 Jan 2025 at 08:44, Yugo NAGATA wrote:
>
> I've attached a updated patch v4 that includes fixes on translate_columns[]
> and ranslate_columns_pre_96[].
>
This looked good to me, so I've pushed both patches.
I changed the column name to "Leakproof?" with a question mark,
because all oth
On Tue, 14 Jan 2025 at 08:51, Alvaro Herrera wrote:
>
> On 2025-Jan-14, Hunaid Sohail wrote:
>
> > I've tried the approach and attached the output. Does this look good?
>
> Hmm, I'm not sure I like the third column particularly; it's noisy to
> have on all the time. I'd leave that for \conninfo+
On Mon, 13 Jan 2025 at 19:23, Alvaro Herrera wrote:
>
> But these don't show the acceptable range. We have these that do:
>
> #: utils/adt/varbit.c:1824 utils/adt/varbit.c:1882
> #, c-format
> msgid "bit index %d out of valid range (0..%d)"
>
> #: utils/adt/varlena.c:3218 utils/adt/varlena.c:3285
On Mon, 13 Jan 2025 at 17:36, Aleksander Alekseev
wrote:
>
> Besides fixing opr_sanity test I corrected error messages:
>
> -ERROR: bytea size 3 out of valid range, 0..2
> +ERROR: bytea out of valid range, ''..'\x'
>
"smallint out of range", "integer out of range" and "bigint out of
range"
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> Here is a new patch version
In expand_generated_columns_in_expr():
+ RangeTblEntry *rte;
+
+ rte = makeNode(RangeTblEntry);
+ rte->relid = RelationGetRelid(rel);
+
+ node = expand_generated_columns_internal(node, re
On Mon, 13 Jan 2025 at 08:44, Alvaro Herrera wrote:
>
> > IMO, we should continue with v35 and add all parameters from
> > PQparameterStatus,
> > as Sami suggested. The names themselves are informative enough.
>
> IMO we need more opinions. Maybe enough other people are not as unhappy
> about the
On Sat, 11 Jan 2025 at 15:42, Tom Lane wrote:
>
> +1, but you also need to update the xml_1.out and xml_2.out files.
> IIRC, xml_1.out is what comes out without --with-libxml.
> I forget what's different about xml_2.out, but you can probably
> just clone the diff for xml.out and be fine.
>
Ah yes
similar code that does quote variable names
properly).
I scanned the rest of ruleutils.c, and didn't find any other issues.
Regards,
Dean
From 868ea003a54adeeae470407321fe4481c95dfccb Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Sat, 11 Jan 2025 11:08:50 +
Subject: [PATCH v1 1/2
On Wed, 4 Dec 2024 at 11:21, Yugo NAGATA wrote:
>
> > Looking through the complete list of psql meta-commands, "leakproof"
> > could plausibly be added to the output of each of the following:
> >
> > \dAo+
> > \dC+
> > \df+
> > \do+
>
> I've attached a updated patch (v3-0001) that include changes
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> One thing I could use some review on is the access control handling and
> security in general. You can create virtual generated columns that have
> their own access privileges but which can read columns that the user
> does not have access
On Mon, 30 Dec 2024 at 15:48, Greg Sabino Mullane wrote:
>
> I like this, very useful. It's a shame about the conflict with \dx (lesson
> for the future: think extra carefully about option namings!). I am impressed
> that \dx \d \d+ \d+x and even \dxx all work as one might intuit with
>
On Fri, 3 Jan 2025 at 19:39, Robert Treat wrote:
>
> This is really nice work. I was curious what you think the status of
> this patch is at this point and if you are still thinking of
> committing it for v18?
>
Thanks for looking. I think that the patch is in good shape, and it
has had a decent
The output from various psql meta-commands such as \df+ can be quite
wide, making it hard to read, and there is another patch [1] that will
make it even wider. The output is much more readable if expanded mode
is used, but it's somewhat inconvenient to keep turning that on and
off, if you don't wan
On Sat, 30 Nov 2024 at 00:38, tsinghualucky...@foxmail.com
wrote:
>
> Dear Dean Rasheed, I have reviewed the v4 patch and it is very thoughtful and
> reasonable, with a very clever attention to detail (plus I am very happy that
> we can get rid of the goto, which I was not
On Fri, 29 Nov 2024 at 13:10, Dean Rasheed wrote:
>
> There are a couple more things that I think need tidying up. I'll post an
> update when I get back to my computer.
>
Here's an update with some cosmetic tidying up, plus a couple of
not-so-cosmetic changes:
The new
On Fri, 29 Nov 2024, 12:01 David Rowley, wrote:
> On Fri, 29 Nov 2024 at 18:50, songjinzhou
> wrote:
> > Hello, thank you and David Rowley for your comments.
> >
> > I have used pgindent to adjust the code format and added comments and
> missing regression test cases. Here is the patch of versio
On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>
> In light of CVE-2024-10976, which was fixed by commit cd7ab57, I'd like to
> propose a bigger change to this area of the code that aims to future-proof
> it a bit. Instead of requiring hackers to carefully cart around whether a
> query refer
On Thu, 28 Nov 2024 at 07:47, 孤傲小二~阿沐 wrote:
>
> Hello hackers, I saw a recent submission: Teach planner how to estimate rows
> for timestamp generate_series. I provide a patch for the numeric type here,
> and a simple test is as follows:
>
> I really want to know your thoughts, please give me f
On Tue, 29 Oct 2024 at 13:05, Dean Rasheed wrote:
>
> Rebased version attached. No other changes.
>
In the light of 7f798aca1d5df290aafad41180baea0ae311b4ee, I guess I
should remove various (void *) casts that this patch adds, copied from
old code. I'll wait a while though, ju
On Fri, 15 Nov 2024 at 09:55, Yugo Nagata wrote:
>
> I'll fixed the patch to add leakproof info to \do+ results, but is it worth
> leaving this info in \dAo+ results, too?
>
I suppose that might still be useful in some contexts.
Looking through the complete list of psql meta-commands, "leakproof
On Thu, 14 Nov 2024 at 16:28, Dmitry Koval wrote:
>
> I think having gamma() and lgamma() functions in PostgreSQL would be
> useful for some users, this is asked [1].
>
Thanks for looking.
> >SELECT gamma(float8 '1e-320');
> ERROR: value out of range: overflow
>
> >SELECT gamma(float8 '0');
>
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
In expand_generated_columns_in_expr():
+/*
+ * XXX For the benefit of triggers, make two passes, so it covers
+ * PRS2_OLD_VARNO and PRS2_NEW_VARNO.
+ */
+node = expand_generated_c
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
What happened with the RLS support? It looks like you moved the code
to expand virtual generated columns back to the first loop in
fireRIRrules(), which doesn't work because RLS policies might contain
references to virtua
1 - 100 of 696 matches
Mail list logo
