Robert Haas escribió: > On Fri, Mar 8, 2013 at 9:18 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > Robert Haas escribió: > >> On Tue, Mar 5, 2013 at 12:45 PM, Alvaro Herrera > >> <alvhe...@2ndquadrant.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.gp9...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
