Re: DELETE with LIMIT (or my first hack)

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