In article <20040811074837.Q17280@megazone.bigpanda.com>,
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>> In exactly the same order as for single-table DELETEs -
>> implementation-defined.
> I think you probably meant in an unspecified order.
> Implementation-defined really doesn't mean anything when you're trying to
> define what it means for a particular implementation. ;)
You're right - what I meant was something like "the same order in
which SELECT without an ORDER BY returns its rows" - something you
can't rely upon.
>> > B) If no join criteria are supplied, is it OK to delete all rows from one of
>> > the tables?
>>
>> Yes - people creating Cartesian products deserve punishment :-)
> What we do here should be related to what we would want to happen on
> a view with a join if we were to make automatically updatable views.
I think automatically updatable views are something like views with
automatically generated INSERT/UPDATE/DELETE rules, aren't they?
Well, my hypothetical multi-table-DELETE would then call the DELETE
rule. Where do you see a problem?
>> I thought about something like that:
>>
>> DELETE [tbl [,tbl]...]
>> FROM fromexp
>>
>> "fromexp" could be anything which is legal after a "SELECT ... FROM",
>> including outer joins and LIMIT clauses.
> Including subselects in FROM? That's a big barrel of fish. How does this
> interact with subselects with union or distinct or group by.
Ouch, didn't think about that.
The general problem seems to be that a table can occur at many places
within one query, and at each place different rows are matched. On
the top level this should not be a problem: just specify the correct
table alias between DELETE and FROM.
Perhaps we could disallow deleting from tables/aliases in deeper
subselect levels?