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 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 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 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, 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 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, 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 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
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 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 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
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 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 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 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 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 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 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 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 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 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 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
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, 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 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 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 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');
> >
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 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
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 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 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, 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 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 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 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 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
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
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 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
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 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
601 - 648 of 648 matches
Mail list logo
