| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: ALTER TABLE ... NOREWRITE option |
| Date: | 2012-12-06 18:21:09 |
| Message-ID: | CA+U5nMK7oXkZ=hicK7cqCV87uiWV8=tOinA=-hrx31XKDF6-jg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6 December 2012 00:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Yes, but it is also the trigger writers problem.
>
> Maybe to some degree. I don't think that a server crash or something
> like a block-read error is ever tolerable though, no matter how silly
> the user is with their event trigger logic. If we go down that road
> it will be impossible to know whether errors that are currently
> reliable indicators of software or hardware problems are in fact
> caused by event triggers. Of course, if an event trigger causes the
> system to error out in some softer way, that's perfectly fine...
How are event triggers more dangerous than normal triggers/functions?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-12-06 18:27:12 | Re: How to check whether the row was modified by this transaction before? |
| Previous Message | Simon Riggs | 2012-12-06 18:16:00 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |