Re: Preventing DELETE and UPDATE without a WHERE clause?

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Chris Campbell" <chris(at)bignerdranch(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Preventing DELETE and UPDATE without a WHERE clause?
Date: 2006-06-17 04:25:34
Message-ID: c2d9e70e0606162125v30127e01i232eeb7bb2ef752d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/16/06, Mark Woodward <pgsql(at)mohawksoft(dot)com> wrote:
> > Chris Campbell <chris(at)bignerdranch(dot)com> writes:
> >> I heard an interesting feature request today: preventing the
> >> execution of a DELETE or UPDATE query that does not have a WHERE clause.
> >
> > These syntaxes are required by the SQL spec. Furthermore, it's easy
> > to imagine far-more-probable cases in which the system wouldn't detect
> > that you'd made a mistake, eg
> >
> > DELETE FROM tab WHERE key > 1
> >
> > where you meant to type
> >
> > DELETE FROM tab WHERE key > 10000000
> >
> > I suggest counseling your client to learn how to use BEGIN/ROLLBACK.
> > This proposal strikes me as falling squarely within the rule about
> > "design a system that even a fool can use, and only a fool will want
> > to use it".
> >
> Just a theory, couldn't a trigger be set up that would case the query to
> tank if it touches too many rows?
>

i haven't tried but maybe a FOR STATEMENT trigger AFTER the event can
ask ROW_COUNT using GET DIAGNOSTICS?

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2006-06-17 06:15:49 Re: MultiXacts & WAL
Previous Message Robert Lor 2006-06-17 04:17:04 Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community