On Thu, 27 Nov 2025 at 17:55, Dean Rasheed wrote:
>
> On Thu, 27 Nov 2025 at 16:55, Tom Lane wrote:
> >
> > I do think there's another way we could attack it. Similarly
> > to the way VALUES RTEs are either processed or skipped by
> > checking the rangetable length, we could pass down the length
On Thu, 27 Nov 2025 at 16:55, Tom Lane wrote:
>
> Hmmm ... I don't love this particular implementation, because it
> is doubling down on the already-undesirable assumption that the
> rule CTEs have no name conflicts with the outer query's CTEs.
> Still, unless somebody sets out to remove that rest
On Thu, 27 Nov 2025 at 14:31, Bernice Southey wrote:
>
> FWIW, I think I found a way to fix my bug that doesn't break your
> rules example. I added a bool to RewriteQuery, and used this to stop
> reprocessing updatable view CTEs. This leaves the rules recursion path
> unchanged. Which means rule C
Dean Rasheed writes:
> Yes, I think that would work, but I think a simpler solution would be
> to just have RewriteQuery() track which CTEs it had already rewritten,
> which can be done just by passing around a list of CTE names.
> Something like the attached.
Hmmm ... I don't love this particula
Dean Rasheed wrote:
> Yes, I think that would work, but I think a simpler solution would be
> to just have RewriteQuery() track which CTEs it had already rewritten,
> which can be done just by passing around a list of CTE names.
> Something like the attached.
I was playing around with an idea I ha
On Wed, 26 Nov 2025 at 21:57, Tom Lane wrote:
>
> I was toying with the idea of decoupling rewriting of WITHs from
> the main recursion. This would look roughly like
>
> 1. Pull out RewriteQuery's first loop into a new function, say
> RewriteQueryCTEs. Call this from QueryRewrite just before cal
Dean Rasheed writes:
> I think it is true that RewriteQuery() doesn't need to rewrite
> individual CTEs multiple times. However, that doesn't mean that it
> doesn't need to process the cteList at all below the top-level. The
> problem is that rule actions may add additional CTEs to the list,
> whi
On Wed, 26 Nov 2025 at 20:29, Bernice Southey wrote:
>
> Bernice Southey wrote:
> > I went through the history and it seemed to me the repeat rewrite was
> > accidental because of the two ways this method can recurse.
> I mean the repeat rewrite of the cteList was accidental, not the
> repeat rew
Bernice Southey wrote:
> I went through the history and it seemed to me the repeat rewrite was
> accidental because of the two ways this method can recurse.
I mean the repeat rewrite of the cteList was accidental, not the
repeat rewrite of views. I couldn't think why a view would mean a
cteList ne
Kirill Reshke wrote:
> Added test are good, but two things:
> 1) Why with.sql and not generated.sql ?
This bug is "with" in combination with "generated identity" and
"updatable view". The current fix targets "with", so that made me pick
"with". It should move to "generated_stored" if the fix is id
Dean Rasheed writes:
> The majority of RewriteQuery() is safe if it's called a second time on
> the same query, because it fully expands all non-SELECT rules and
> auto-updatable target views, so the second time round, it would do
> nothing of that kind. However, evidently it's not safe to call
>
On Wed, 26 Nov 2025 at 12:13, Kirill Reshke wrote:
>
> On Wed, 26 Nov 2025 at 13:34, Bernice Southey
> wrote:
>
> > I get an odd error if a CTE inserts a GENERATED ALWAYS AS IDENTITY
> > column, and then tries to modify an automatically updatable view.
> >
> > create table t(i int generated alwa
On Wed, 26 Nov 2025 at 13:34, Bernice Southey wrote:
>
> Hi,
Hi!
> I get an odd error if a CTE inserts a GENERATED ALWAYS AS IDENTITY
> column, and then tries to modify an automatically updatable view.
>
> create table t(i int generated always as identity);
> create table base(j int);
> create v
13 matches
Mail list logo
