On Fri, 28 Nov 2025 at 09:21, Bernice Southey wrote:
>
> This is neat.
> Should the test be the rules one? Updatable views are more used, but
> your rules example has more coverage.
Yes, I think that's probably better. I've tweaked the test to use both
rules and updatable views, so that it has to
On Thu, 27 Nov 2025 at 21:40, Tom Lane wrote:
>
> Yeah, this looks pretty good. Two nitpicky suggestions:
>
> * Perhaps using foreach_current_index() would be better than
> adding the separate loop variable "i" in RewriteQuery.
Ah, good point. I'd forgotten about that macro.
> * I think it woul
Dean Rasheed wrote:
> Here's an update, doing it that way. It does appear somewhat neater.
This is neat.
Should the test be the rules one? Updatable views are more used, but
your rules example has more coverage.
Thanks, Bernice
Dean Rasheed writes:
> Here's an update, doing it that way. It does appear somewhat neater.
Yeah, this looks pretty good. Two nitpicky suggestions:
* Perhaps using foreach_current_index() would be better than
adding the separate loop variable "i" in RewriteQuery.
* I think it would be wise to
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
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 view v as select * from base;
with cte as (insert into t default values ret
18 matches
Mail list logo
