Skip site navigation (1) Skip section navigation (2)

Re: DELETE with LIMIT (or my first hack)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Daniel Loureiro <daniel(at)termasa(dot)com(dot)br>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Csaba Nagy <ncslists(at)googlemail(dot)com>
Subject: Re: DELETE with LIMIT (or my first hack)
Date: 2010-11-30 20:34:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 11/30/2010 03:16 PM, Andres Freund wrote:
> On Tuesday 30 November 2010 20:24:52 Marko Tiikkaja wrote:
>>> On 11/30/2010 02:12 PM, Kevin Grittner wrote:
>>>> Daniel Loureiro<daniel(at)termasa(dot)com(dot)br>    wrote:
>>>>> to me the key its security - its a anti-DBA-with-lack-of-attention
>>>>> feature.
>>>> Well, it seems pretty weak to me for that purpose.  You still trash
>>>> data, and you don't have any immediate clue as to what.
>>> I agree, that argument is completely misconceived. If the DBA is paying
>>> enough attention to use LIMIT, s/he should be paying enough attention
>>> not to do damage in the first place. If that were the only argument in
>>> its favor I'd be completely against the feature.
>> I don't buy the argument either; why would you put a LIMIT there and
>> delete one row by accident when you could put a BEGIN; in front and not
>> do any damage at all?
> Because the delete of the whole table may take awfully long?

I don't see that that has anything to do with restricting damage. LIMIT 
might be useful for the reason you give, but not as any sort of 
protection against DBA carelessness. That's what the discussion above is 



In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-11-30 20:49:07
Subject: Re: profiling connection overhead
Previous:From: Greg SmithDate: 2010-11-30 20:29:57
Subject: Re: Spread checkpoint sync

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group