Re: allow LIMIT in UPDATE and DELETE - Mailing list pgsql-general

From Shelby Cain
Subject Re: allow LIMIT in UPDATE and DELETE
Date
Msg-id 20060519162549.22224.qmail@web37210.mail.mud.yahoo.com
Whole thread Raw
In response to Re: allow LIMIT in UPDATE and DELETE  (SCassidy@overlandstorage.com)
Responses Re: allow LIMIT in UPDATE and DELETE  (Csaba Nagy <nagy@ecircle-ag.com>)
List pgsql-general
>----- Original Message ----
>From: SCassidy@overlandstorage.com
>To: Csaba Nagy <nagy@ecircle-ag.com>
>Cc: Postgres general mailing list <pgsql-general@postgresql.org>; >pgsql-general-owner@postgresql.org
>Sent: Friday, May 19, 2006 10:43:43 AM
>Subject: Re: [GENERAL] allow LIMIT in UPDATE and DELETE
>
>Personally, I have never wanted a DELETE or UPDATE with LIMIT.  The one
>time I did something similar in Oracle, I used partitions, and just dropped
>or truncated the partition containing the old data.
>

Yeah, that’s the proper way to handle the issue assuming that sufficient forethought was put into the design of the
database. It becomes trivial to drop a partition part of your weekly/monthly maintenance. 

Unfortunately, when dealing with legacy database systems that have grown in a very organic way over a span of 5-10
yearsyou don't have much control over the schema and there is significant inertia present to leave things as they are.
Asan example, the DBA group at the client I'm currently working has their databases managed by IBM global services and
theywill push back on altering a table definition to use partitioning as it costs the organization money to have those
changesput into production.  Having a internal developer use a script to perform such maintenance as a batch process is
considered"free" so you can guess how many such processes have been created over the years. 

Regards,

Shelby Cain





pgsql-general by date:

Previous
From: Csaba Nagy
Date:
Subject: Re: allow LIMIT in UPDATE and DELETE
Next
From: Csaba Nagy
Date:
Subject: Re: allow LIMIT in UPDATE and DELETE