Greg Stark writes:
> You would have to write something like
> UPDATE foo set a = (select aa from bar where...)
> b = (select bb from bar where...)
> and then the optimizer would have to notice the duplicates and
> consolidate them? That seems inconvenient (and fragile).
On Tue, Aug 25, 2009 at 2:50 PM, Tom Lane wrote:
> On the performance front: yeah, you can recast most joins as subqueries,
> but you tend to end up with the equivalent of a nestloop plan. Works
> okay for small numbers of rows, scales horribly.
Well that's our problem isn't it? I thought we were
Tom Lane wrote:
Robert Haas writes:
On Mon, Aug 24, 2009 at 9:31 PM, Josh Berkus wrote:
What I don't get is why this is such a usability issue. Subqueries in
DELETE FROM work perfectly well, and provide more flexibility than most
users know what to do with.
It's both a
Robert Haas writes:
> On Mon, Aug 24, 2009 at 9:31 PM, Josh Berkus wrote:
>> What I don't get is why this is such a usability issue. Subqueries in
>> DELETE FROM work perfectly well, and provide more flexibility than most
>> users know what to do with.
> It's both a usability issue and a perform
On Mon, Aug 24, 2009 at 9:31 PM, Josh Berkus wrote:
> All,
>
>>> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
>>>
>>> but we have always considered that the target is *not* to be identified
>>> with any member of the FROM/USING clause, so it would be a serious
>>> compatibility brea
Josh Berkus wrote:
> All,
>
> >> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
> >>
> >> but we have always considered that the target is *not* to be identified
> >> with any member of the FROM/USING clause, so it would be a serious
> >> compatibility break to change that now.
>
>
> With proper foreign keys and ON DELETE CASCADE, why would supporting
> such syntax even be necessary?
Porting existing abstraction layers from ANSI JOINs to ON DELETE CASCADE
is complicated.
> What I don't get is why this is such a usability issue. Subqueries in
> DELETE FROM work perfectly we
All,
>> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
>>
>> but we have always considered that the target is *not* to be identified
>> with any member of the FROM/USING clause, so it would be a serious
>> compatibility break to change that now.
What I don't get is why this is such
Bruce Momjian writes:
> What we cannot currently do is reference test twice:
> test=> DELETE FROM test USING test;
> ERROR: table name "test" specified more than once
> test=> DELETE FROM test t USING test t;
> ERROR: table name "t" specified more than once
Hmm
Tom Lane wrote:
> Alvaro Herrera writes:
> > Bruce Momjian wrote:
> >> So the problem is that our DELETE ... USING does not allow ANSI join
> >> syntax? Can that be added?
>
> > Not sure about that. USING is already an extension to the standard, so
> > if we extend it a bit more, it can't be a
On Mon, Aug 24, 2009 at 01:41:28PM -0400, Tom Lane wrote:
> The real problem with this is that all the
> good candidates for the reserved word are things people are probably
> already using as aliases, so we'd have a large risk of breaking existing
> queries. We could avoid that with a sufficientl
Robert Haas writes:
> 2009/8/24 Tom Lane :
>> ... Some other systems
>> allow it by letting you re-specify the target in the other clause,
>> equivalently to
>>
>> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
>>
>> but we have always considered that the target is *not* to be iden
2009/8/24 Tom Lane :
> Alvaro Herrera writes:
>> Bruce Momjian wrote:
>>> So the problem is that our DELETE ... USING does not allow ANSI join
>>> syntax? Can that be added?
>
>> Not sure about that. USING is already an extension to the standard, so
>> if we extend it a bit more, it can't be a p
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> So the problem is that our DELETE ... USING does not allow ANSI join
>> syntax? Can that be added?
> Not sure about that. USING is already an extension to the standard, so
> if we extend it a bit more, it can't be a problem, can it?
I don't see
In response to Bruce Momjian :
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > > Ultimately, why not allow:
> > > >
> > > > DELETE h, tn
> > > > FROM history AS h
> > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > >
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > > Ultimately, why not allow:
> > > > >
> > > > > DELETE h, tn
> > > > > FROM history AS h
> > > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > > INNER JOIN term_data AS td
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > > Ultimately, why not allow:
> > > >
> > > > DELETE h, tn
> > > > FROM history AS h
> > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > > WHERE h.uid
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > > Ultimately, why not allow:
> > >
> > > DELETE h, tn
> > > FROM history AS h
> > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > WHERE h.uid = 2067 AND td.vid = 2
> > >
> > > IMHO
Bruce Momjian wrote:
> > Ultimately, why not allow:
> >
> > DELETE h, tn
> > FROM history AS h
> > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > WHERE h.uid = 2067 AND td.vid = 2
> >
> > IMHO this would improve compliance towards other
Jean-Michel Pour? wrote:
-- Start of PGP signed section.
> Dear Friends,
>
> First, thank you very much for considering a fix on the GROUP BY issue.
> I am starting a new thread about another issue:
>
> It seems that DELETE cannot understand INNER JOINS and needs HAVING.
>
> Read:
> http://dru
Dear Friends,
First, thank you very much for considering a fix on the GROUP BY issue.
I am starting a new thread about another issue:
It seems that DELETE cannot understand INNER JOINS and needs HAVING.
Read:
http://drupal.org/node/62 (main message)
http://drupal.org/node/555648
I don't s
21 matches
Mail list logo
