Re: top-level DML under CTEs

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: top-level DML under CTEs
Дата
Msg-id 4C8FDAF1.5010601@cs.helsinki.fi
обсуждение исходный текст
Ответ на Re: top-level DML under CTEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: top-level DML under CTEs  (Robert Haas <robertmhaas@gmail.com>)
Re: top-level DML under CTEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: top-level DML under CTEs  (Hitoshi Harada <umi.tanuki@gmail.com>)
Список pgsql-hackers
On 2010-09-14 10:51 PM, Tom Lane wrote:
> Hitoshi Harada<umi.tanuki@gmail.com>  writes:
>> 2010/9/15 Marko Tiikkaja<marko.tiikkaja@cs.helsinki.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: top-level DML under CTEs
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Sync Replication with transaction-controlled durability