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 <br...@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 <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + >
