its pretty clear to me that's 2 different needs here, both linked to DELETE/UPDATE behavior.
A) an feature MySQL-like which will DELETE/UPDATE just K tuples
B) an feature to protect the database in case the DBA forget the "WHERE" statement
I think that the first feature its pretty reasonable for many reasons - some of then listed below (not in order of importance):
1) MySql compatibility: will turn more easy intercompatibility
2) speed: why scan all the table if its expected to affect just one row ?
3) possibility to batch operation (paginate UPDATE/DELETE)
4) easy-to-use in some operations (like delete the row with higher Y field): its necessary to implement with "ORDER BY"
5) some others independent (and possibly weird needs) things that i forget
The second feature its something to turn the PostgreSQL more secure: in others words armor from DBA. The syntax maybe will something like "DELETE .... ASSERT 1", or an explicit keyword for this, like: "DELETEO ...". So, the mechanism should be give an error and rollback if the command affect more than specified tuples. IMHO this its a very weird syntax and so much non-standard SQL. So I believe this not a so-necessary feature. Ok I known that I started this discussion (around this weird feature, not the first and reasonable feature), but was good to instigate others thoughts.
Sds,
--
Daniel Loureiro
2010/11/30 Bruce Momjian
<bruce@momjian.us>Daniel Loureiro wrote:
> > 3. This doesn't work tremendously well for inheritance trees, where
> > ModifyTable acts as sort of an implicit Append node. You can't just
> > funnel all the tuples through one Sort or Limit node because they aren't
> > all the same rowtype. (Limit might perhaps not care, but Sort will.)
> > But you can't have a separate Sort/Limit for each table either, because
> > that would give the wrong behavior. Another problem with funneling all
> > the rows through one Sort/Limit is that ModifyTable did need to know
> > which table each row came from, so it can apply the modify to the right
> > table.
>
> So I guess that I have choose the wrong hack to start.
>
> Just for curiosity, why the result of "WHERE" filter (in
> SELECT/DELETE/UPDATE) is not put in memory, i.e. an array of ctid, like an
> buffer and then executed by SELECT/DELETE/UPDATE at once ?
Informix dbaccess would prompt a user for confirmation if it saw a
DELETE with no WHERE.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +