its pretty clear to me that's 2 different needs here, both linked to
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"
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.
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
> > > 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
> > 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. +
In response to
pgsql-hackers by date
|Next:||From: Valentine Gogichashvili||Date: 2010-12-01 11:06:19|
|Subject: Re: [HACKERS] Improved JDBC driver part 2|
|Previous:||From: ghatpande||Date: 2010-12-01 10:46:12|
|Subject: Re: Proposal: First step towards Intelligent,