Re: LIMIT for UPDATE and DELETE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Rukh Meski <rukh(dot)meski(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LIMIT for UPDATE and DELETE
Date: 2014-09-03 15:39:25
Message-ID: CA+TgmoYtRJcuLHfOpzWb8oJksNO5tK=mVKeqJuwf5qr6SayXkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> On 9/3/14 4:46 PM, Robert Haas wrote:
>> Making it
>> suck more because you don't think it's as important as your feature
>> is, in my opinion, not cool.
>
> I really can't see how that would make inheritance suck *more*. You can't
> do UPDATE .. ORDER BY now, and you wouldn't be able to do it after the
> patch. Yeah, sure, perhaps people using inheritance might feel left out,
> but surely that would just motivate them to work on improving it.

I think it's entirely reasonable for us to require that all new SQL
features should be required to work with or without inheritance. If
we took the opposition position, and said that the only things that
need to work with inheritance are the ones that existed at the time
inheritance was introduced, then we'd not need to worry about it not
only for this feature but for row-level security and SKIP LOCKED and
GROUPING SETS and, going back a bit further, materialized views and
security-barrier views and LATERAL and CTEs and on and on. Perhaps
not all of those require any special handling for inheritance
hierarchies, but some of them surely did, and if even 10% of the SQL
features that we have added since table inheritance were allowed to
opt out of supporting it, we'd have a broken and unusable feature
today.

Now some people might argue that we have that anyway, but the fact is
that a lot of people are using inheritance today, even with all its
flaws, and they wouldn't be if there were a long laundry list of
limitations that didn't apply to regular tables. We should be looking
to lift the limitations that currently exist, not add more.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-03 15:47:45 Re: Misleading error message in logical decoding for binary plugins
Previous Message Robert Haas 2014-09-03 15:23:21 Re: Misleading error message in logical decoding for binary plugins