Re: Deprecating RULES - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Deprecating RULES
Date
Msg-id CAAZKuFaofibS5NqYCDJJ2nGn7DABSkwyU9isC5TGUr9B0Ht73A@mail.gmail.com
Whole thread Raw
In response to Re: Deprecating RULES  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Deprecating RULES  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Thu, Oct 18, 2012 at 6:46 AM, Andrew Dunstan <andrew@dunslane.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



pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: Bug in -c CLI option of pg_dump/pg_restore
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Deprecations in authentication