Re: Deprecating RULES

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deprecating RULES
Date: 2012-10-18 17:11:54
Message-ID: CAAZKuFaofibS5NqYCDJJ2nGn7DABSkwyU9isC5TGUr9B0Ht73A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 18, 2012 at 6:46 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 10/17/2012 07:25 PM, Tom Lane wrote:
>
>>
>> I'm fairly annoyed by the entire tenor of this conversation, because
>> the people who are hollering the loudest seem to be people who have
>> never actually touched any of the rules code, but nonetheless seem
>> prepared to tell those of us who have what to spend our time on.
>
>
> +1
>
> I too have been quite annoyed.

Sorry that I'm an offender. I also did not like the way the
conversation was going for some time; for me, I felt like I didn't
understand a lot of the terse rejections that materialized immediately
on behalf of users that I personally cannot identify, and I felt those
rejections weren't in a neutral language either that encouraged
clarification. I'm glad things have moved beyond that.

> The biggest pain people have mentioned is that they don't work with COPY. I
> am in fact about to start working on a project which will probably alleviate
> that pain point. I'm not going to say much more, and I would not have said
> anything right now except that there is this sudden rush to deprecate rules,
> or announce a future removal of the feature. However, I hope to have a
> proposal to put to the community by about the end of November.

I have encountered this as a papercut.

Here's another use case that in my history with RULES that didn't seem
to pan out so well: In my recollection, one way to use rules is to
retarget operations that happen against a view and move them to a
table, and as I recall to make this work as one expected one had to
have a very wordy RULE (for UPDATEs) with a litany of (fairly simple)
equality and not-null conditions to make it work as one would expect
(to not under-constrain the UPDATE). This became a maintenance
headache whenever attributes were added to the underlying relation.

It was also quite complex, as I recall, when one wanted to maintain an
interface but normalize the underlying table and split writes into two
or more places.

It has been quite some time, does that sound like a correct rendering
of a problem?

--
fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2012-10-18 17:20:04 Re: Deprecations in authentication
Previous Message Guillaume Lelarge 2012-10-18 17:08:53 Re: Bug in -c CLI option of pg_dump/pg_restore