From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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 Triggerg |
Date: | 2013-03-08 16:07:55 |
Message-ID: | 20130308160755.GB5352@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas escribió:
> On Fri, Mar 8, 2013 at 9:18 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > Robert Haas escribió:
> >> On Tue, Mar 5, 2013 at 12:45 PM, Alvaro Herrera
> >> <alvherre(at)2ndquadrant(dot)com> wrote:
> >> > Hmm, maybe I should be considering a pair of macros instead --
> >> > UTILITY_START_DROP and UTILITY_END_DROP. I'll give this a try. Other
> >> > ideas are welcome.
> >>
> >> That seems like a possibly promising idea. I do wonder how well any
> >> of this is going to scale.
> >
> > I did followup with a patch implementing that; did you see it?
>
> No, sorry. Which thread is it on?
http://www.postgresql.org/message-id/20130305214218.GP9507@alvh.no-ip.org
I think Gmail's feature of breaking threads when subject changes is an
annoyance here. I somehow added a "g" at the end and later dropped it.
I didn't remember that behavior of Gmail's.
> > The current idea of having a
> > function that returns objects affected by the command seems relatively
> > sensible. For drops, it seems pretty straighforward so far. For CREATE
> > it's probably somewhat more involved, but seems doable in principle (but
> > yes, we're going to have to sprinkle ProcessUtility() with a lot of
> > UTILITY_START/END_CREATE calls).
> >
> > Not sure about ALTER; maybe we will need a completely different idea to
> > attack that.
>
> I am inclined to think that putting this logic in ProcessUtility isn't
> scalable, even for CREATE, and even moreso for ALTER, unless we can
> put it around everything in that function, rather than each command
> individually. Suppose for example that on entry to that function we
> simply did this:
>
> if (isCompleteQuery)
> ++CompleteQueryNestingLevel;
>
> ...and at exit, we did the reverse. This could work a bit like the
> GUC nesting level.
Hmm, this seems an interesting idea to explore.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2013-03-08 16:37:34 | Re: Support for REINDEX CONCURRENTLY |
Previous Message | Josh Kupershmidt | 2013-03-08 15:58:57 | Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |