Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules
Date: 2014-06-17 14:02:51
Message-ID: 17030.1403013771@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Would it not be possible to use WITH here, like:

> WITH bar AS ( ... subselect ... )
> INSERT INTO foolog VALUES (bar.a, bar.b, ...)

Don't think it works if the sub-select is correlated.

Consider something like

UPDATE summary_table s
SET (sumx, sumy) = (SELECT sum(x), sum(y) FROM detail_table d
WHERE d.group = s.group)

and suppose we have a logging rule like the above on summary_table.
You can't push the sub-select into a WITH because it depends on
s.group. With sufficient intelligence you could rewrite the query
entirely, I guess, but no simple transformation is going to cope.

But come to think of it, WITH is already an interesting precedent: if you
look into rewriteHandler.c you'll notice a boatload of corner cases where
the rewriter just throws up its hands for various combinations of rules
and statements containing WITH. So maybe that lends a bit more weight
to Andres' position that it's okay to consider this an unimplemented
feature.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-17 14:08:31 Re: avoiding tuple copying in btree index builds
Previous Message Robert Haas 2014-06-17 13:57:37 Re: avoiding tuple copying in btree index builds