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: | 4CF55FE2.70007@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
about.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-30 20:49:07 | Re: profiling connection overhead |
Previous Message | Greg Smith | 2010-11-30 20:29:57 | Re: Spread checkpoint sync |