From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: top-level DML under CTEs |
Date: | 2010-09-14 20:28:33 |
Message-ID: | 4C8FDAF1.5010601@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-rrreviewers |
On 2010-09-14 10:51 PM, Tom Lane wrote:
> Hitoshi Harada<umi(dot)tanuki(at)gmail(dot)com> writes:
>> 2010/9/15 Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>:
>>> In the email you referred to, Tom was concerned about the case where these
>>> WITH lists have different RECURSIVE declarations. This patch makes both
>>> RECURSIVE if either of them is. I can think of cases where that might lead
>>> to surprising behaviour, but the chances of any of those happening in real
>>> life seem pretty slim.
>
>> Does that cause surprising behavior?
>
> My recollection is that whether a CTE is marked RECURSIVE or not affects
> its scope of visibility, so that confusing the two cases can result in
> flat-out incorrect parser behavior.
The worst I can think of is:
CREATE TABLE foo(a int);
WITH t AS (SELECT * FROM foo)
INSERT INTO bar
WITH RECURSIVE foo (SELECT 1 AS a)
SELECT * FROM t;
t will actually be populated with the results of the CTE, not the table foo.
I don't think this is a huge problem in real life, but if someone thinks
otherwise, I think we could just error out if the lists have a different
RECURSIVE definition.
Anyone have a worse example? Thoughts?
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-09-14 20:36:24 | Re: Sync Replication with transaction-controlled durability |
Previous Message | Tom Lane | 2010-09-14 19:51:56 | Re: top-level DML under CTEs |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-14 22:49:29 | Re: top-level DML under CTEs |
Previous Message | Tom Lane | 2010-09-14 19:51:56 | Re: top-level DML under CTEs |