In article <[EMAIL PROTECTED]>, Stephan Szabo <[EMAIL PROTECTED]> 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? ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org