| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: sql_drop Event Trigger |
| Date: | 2013-02-21 17:38:27 |
| Message-ID: | CA+TgmoYBEujrS6krQ4s9pYDNwQ0EcGQfr87pkQMT8mKpQ0riSA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 21, 2013 at 12:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> There's also code to re-obtain the list of objects to drop after the
>> event trigger functions have run; the second list is compared to the
>> first one, and if they differ, an error is raised.
>
> This is definitely an improvement. I am not 100% clear on whether
> this is sufficient, but it sure seems a lot better than punting.
What if the object that gets whacked around is one of the named
objects rather than some dependency thereof? Suppose for example that
the event trigger drops the same object that the user tried to drop.
We need to error out cleanly in that case, not blindly proceed with
the drop.
(In the worst case, somebody could create an unrelated object with the
same OID and we could latch onto and drop that one. Seems remote
unless the user has a way to fiddle with the OID counter, but if it
happened it would be bad.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-02-21 17:39:35 | Re: [DOCS] Contrib module "xml2" status |
| Previous Message | Alvaro Herrera | 2013-02-21 17:38:05 | relpath() to src/common |