On Tue, Jun 17, 2014 at 9:02 AM, Tom Lane wrote:
> 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 contai
Martijn van Oosterhout 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) = (SELEC
On 2014-06-17 09:46:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-17 11:22:17 +0200, Vik Fearing wrote:
> >> On 06/17/2014 09:43 AM, Hannu Krosing wrote:
> >>> Was'nt there a plan (consensus?) about deprecating rules altogether ?
>
> >> I believe that was just for user access t
Andres Freund writes:
> On 2014-06-17 11:22:17 +0200, Vik Fearing wrote:
>> On 06/17/2014 09:43 AM, Hannu Krosing wrote:
>>> Was'nt there a plan (consensus?) about deprecating rules altogether ?
>> I believe that was just for user access to them, ie CREATE RULE. I
>> don't think there was ever q
On 2014-06-17 11:22:17 +0200, Vik Fearing wrote:
> On 06/17/2014 09:43 AM, Hannu Krosing wrote:
> > On 06/14/2014 09:35 PM, Tom Lane wrote:
> >> > As I mentioned awhile ago, I'm thinking about implementing the
> >> > SQL-standard construct
> >> >
> >> > UPDATE foo SET ..., (a,b,...) = (SELECT x,y,
On 06/17/2014 11:22 AM, Vik Fearing wrote:
> On 06/17/2014 09:43 AM, Hannu Krosing wrote:
>> On 06/14/2014 09:35 PM, Tom Lane wrote:
As I mentioned awhile ago, I'm thinking about implementing the
SQL-standard construct
UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ...
>>>
On 06/17/2014 09:43 AM, Hannu Krosing wrote:
> On 06/14/2014 09:35 PM, Tom Lane wrote:
>> > As I mentioned awhile ago, I'm thinking about implementing the
>> > SQL-standard construct
>> >
>> >UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ...
>> >
>> > I've run into a rather nasty problem, w
On 06/14/2014 09:35 PM, Tom Lane wrote:
> As I mentioned awhile ago, I'm thinking about implementing the
> SQL-standard construct
>
> UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ...
>
> I've run into a rather nasty problem, which is how does this interact
> with expansion of NEW referen
On Sat, Jun 14, 2014 at 03:35:33PM -0400, Tom Lane wrote:
> The best that I think is reasonable to do in such cases is to pull out
> a separate copy of the sub-select for each actual NEW reference in a
> rule query. So the example above would give rise to an expanded
> rule query along the lines o
On 2014-06-14 19:27:03 -0500, Jim Nasby wrote:
> On 6/14/14, 3:51 PM, Andres Freund wrote:
> >>Hm. But you might as well use a trigger, no? Is anyone likely to
> >>>actually be doing such a thing?
> >I don't think anybody is likely to do such a thing on an actual table,
> >but INSTEAD OF for view
On 6/14/14, 3:51 PM, Andres Freund wrote:
Hm. But you might as well use a trigger, no? Is anyone likely to
>actually be doing such a thing?
I don't think anybody is likely to do such a thing on an actual table,
but INSTEAD OF for views is pretty new. For a long time rules were the
the only way
On 2014-06-14 16:44:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> >> Well, it wouldn't be "unsafe" (barring volatile functions in the UPDATE,
> >> which are unsafe already). It might be slow, but that's probably better
> >> than failing.
>
Andres Freund writes:
> On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
>> Well, it wouldn't be "unsafe" (barring volatile functions in the UPDATE,
>> which are unsafe already). It might be slow, but that's probably better
>> than failing.
> I forgot the details, but IIRC it's possible to write a
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hi,
> > On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
> >> Given that ON UPDATE rules are close to being a deprecated feature,
> >> it doesn't seem appropriate to work harder than this; and frankly
> >> I don't see how we co
Andres Freund writes:
> Hi,
> On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
>> Given that ON UPDATE rules are close to being a deprecated feature,
>> it doesn't seem appropriate to work harder than this; and frankly
>> I don't see how we could avoid multiple sub-select evaluations anyway,
>> if th
Hi,
On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
> Given that ON UPDATE rules are close to being a deprecated feature,
> it doesn't seem appropriate to work harder than this; and frankly
> I don't see how we could avoid multiple sub-select evaluations anyway,
> if the NEW references are in WHERE
As I mentioned awhile ago, I'm thinking about implementing the
SQL-standard construct
UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ...
I've run into a rather nasty problem, which is how does this interact
with expansion of NEW references in ON UPDATE rules? For example,
suppose foo
17 matches
Mail list logo
