From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using results from INSERT ... RETURNING |
Date: | 2009-10-04 17:13:26 |
Message-ID: | 7690046D-9A49-4189-A33C-14F8E5D2BD8E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 4, 2009, at 11:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, I think a patch to implement writeable CTEs is probably going
>> to
>> have to handle this case - I don't think we can just ignore rewrite
>> rules when processing a CTE. But it does seem to be beyond the scope
>> of the current patch.
>
> I hadn't been paying too much attention to this thread, but ... why
> is anyone worrying about that? Rewrite rules are not the concern
> of either the planner or the executor. A "do also" rule will result
> in two entirely separate Query trees, which will each be planned
> separately and executed separately. Any given executor run only
> has to think about one type of DML command --- otherwise the executor
> would be broken already, since it takes only one command-type
> argument.
If an INSERT/UPDATE/DELETE appears within a CTE, it will still need to
be rewritten. But you're right that this is irrelevant to the present
patch; I just didn't see that at once.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-04 17:16:50 | Re: Using results from INSERT ... RETURNING |
Previous Message | Marko Tiikkaja | 2009-10-04 16:24:41 | Re: Using results from INSERT ... RETURNING |