Re: Add Missing From?

In article <20040811074837(dot)Q17280(at)megazone(dot)bigpanda(dot)com>,
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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?