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
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 |