Richard Guo writes:
> BTW, from catversion.h I read:
> * Another common reason for a catversion update is a change in parsetree
> * external representation, since serialized parsetrees appear in stored
> * rules and new-style SQL functions. Almost any change in primnodes.h or
> *
On Fri, Jul 5, 2024 at 5:51 AM Andres Freund wrote:
> On 2024-07-01 16:29:16 +0800, Richard Guo wrote:
> > Here is an updated version of this patchset. I've run pgindent for it,
> > and also tweaked the commit messages a bit.
> >
> > In principle, 0001 can be backpatched to all supported
On Thu, Jul 4, 2024 at 6:02 PM Ashutosh Bapat
wrote:
> On Mon, Jul 1, 2024 at 1:59 PM Richard Guo wrote:
> > Here is an updated version of this patchset. I've run pgindent for it,
> > and also tweaked the commit messages a bit.
> >
> > In principle, 0001 can be backpatched to all supported
On 2024-07-01 16:29:16 +0800, Richard Guo wrote:
> On Mon, Jun 10, 2024 at 5:05 PM Richard Guo wrote:
> > This patchset does not apply any more. Here is a new rebase.
>
> Here is an updated version of this patchset. I've run pgindent for it,
> and also tweaked the commit messages a bit.
>
>
On Mon, Jul 1, 2024 at 1:59 PM Richard Guo wrote:
>
> On Mon, Jun 10, 2024 at 5:05 PM Richard Guo wrote:
> > This patchset does not apply any more. Here is a new rebase.
>
> Here is an updated version of this patchset. I've run pgindent for it,
> and also tweaked the commit messages a bit.
>
>
On Mon, Jun 10, 2024 at 5:05 PM Richard Guo wrote:
> This patchset does not apply any more. Here is a new rebase.
Here is an updated version of this patchset. I've run pgindent for it,
and also tweaked the commit messages a bit.
In principle, 0001 can be backpatched to all supported versions
On Wed, Jun 5, 2024 at 5:42 PM Richard Guo wrote:
> Hence here is the v7 patchset. I've also added detailed commit messages
> for the two patches.
This patchset does not apply any more. Here is a new rebase.
While at it, I added more checks for 'root->group_rtindex', and also
added a new test
On Fri, May 24, 2024 at 9:08 PM Richard Guo wrote:
> On the basis of the parser infrastructure fixup, 0002 patch adds the
> nullingrel bit that references the grouping RTE to the grouping
> expressions.
I found a bug in the v6 patch. The following query would trigger the
Assert in
On the basis of the parser infrastructure fixup, 0002 patch adds the
nullingrel bit that references the grouping RTE to the grouping
expressions.
However, it seems to me that we have to manually remove this nullingrel
bit from expressions in various cases where these expressions are
logically
On Fri, May 17, 2024 at 5:41 PM Richard Guo wrote:
> I've spent some more time on this patch, and now it passes all the
> regression tests. But I had to hack explain.c and ruleutils.c to make
> the varprefix stuff work as it did before, which is not great.
>
I've realized that I made a mistake
On Thu, May 16, 2024 at 5:43 PM Richard Guo wrote:
> I have experimented with this approach, and here is the outcome. The
> patch fixes Geoff's query, but it's still somewhat messy as I'm not
> experienced enough in the parser code. And the patch has not yet
> implemented the nullingrel bit
On Sun, Jan 7, 2024 at 4:59 AM Tom Lane wrote:
> I don't think this is going in quite the right direction. We have
> many serious problems with grouping sets (latest one today at [1]),
> and I don't believe that hacking around EquivalenceClasses is going
> to fix them all.
>
> I think that what
> On 11 Jan 2024, at 20:10, vignesh C wrote:
>
> I have changed the status of the patch to "Waiting on Author" as Tom
> Lane's comments have not yet been addressed, feel free to address them
> and update the commitfest entry accordingly.
This CF entry seems to be a fix for actually
On Thu, 7 Dec 2023 at 13:52, Richard Guo wrote:
>
>
> On Mon, Sep 25, 2023 at 3:11 PM Richard Guo wrote:
>>
>> If the grouping expression is a Var or PHV, we can just set its
>> nullingrels, very straightforward. For an expression that is neither a
>> Var nor a PHV, I'm not quite sure how to
Richard Guo writes:
> For a variable-free expression, if it contains volatile functions, SRFs,
> aggregates, or window functions, it would not be treated as a member of
> EC that is redundant (see get_eclass_for_sort_expr()). That means it
> would not be removed from the pathkeys list, so we do
On Mon, Sep 25, 2023 at 3:11 PM Richard Guo wrote:
> If the grouping expression is a Var or PHV, we can just set its
> nullingrels, very straightforward. For an expression that is neither a
> Var nor a PHV, I'm not quite sure how to set the nullingrels. I tried
> the idea of wrapping it in a
On Thu, Nov 16, 2023 at 11:25 PM Alena Rybakina
wrote:
> I noticed that this query worked correctly in the main branch with the
> inequality operator:
>
> postgres=# select distinct on (a, b) a, b from (values (3, 1), (2, 2)) as
> t (a, b) where a > b group by grouping sets((a, b), (a)); a | b
Hi! Thank you for your work on the subject.
On 25.09.2023 10:11, Richard Guo wrote:
I think I've come across a wrong result issue with grouping sets, as
shown by the query below.
-- result is correct with only grouping sets
select a, b
from (values (1, 1), (2, 2)) as t (a, b) where a = b
group
On Mon, Sep 25, 2023 at 3:11 PM Richard Guo wrote:
> I think the root cause is that when we generate distinct_pathkeys, we
> failed to realize that Var 'b' might be nullable by the grouping sets,
> so it's no longer always equal to Var 'a'. It's not correct to deem
> that the PathKey for 'b' is
I think I've come across a wrong result issue with grouping sets, as
shown by the query below.
-- result is correct with only grouping sets
select a, b
from (values (1, 1), (2, 2)) as t (a, b) where a = b
group by grouping sets((a, b), (a));
a | b
---+---
1 | 1
1 |
2 | 2
2 |
(4 rows)
--
20 matches
Mail list logo
