Tom Lane wrote: > One particular case of interest is in truncate.out, where the > table-at-a-time implementation of DROP TABLE is clearly exposed > by the fact that you get multiple NOTICEs. I wonder if it would > be worth refactoring the code so that a multiple-object DROP is > implemented via performMultipleDeletions(). This would have more > than just cosmetic advantages: it would no longer matter what > order you listed the tables in. But the refactoring required looks > bigger and more tedious than I want to tackle right now.
Hmm, this is a bit ugly. I'd vote for doing the refactoring. However, I'd say you should commit the patch you currently have and let one of the younger hackers fix that problem -- it looks like an good beginner project. > I also want to note that we've historically had the code report > auto-cascade drops as DEBUG2 messages. I tried to merge those reports > into the main one but it was a complete mess :-( because the client and > server-log messages might have different numbers of entries depending on > their log-level settings. Almost the first case I tried favored me with > NOTICE: drop cascades to 0 other object(s) > DETAIL: > reported to the client (with the server log of course saying something > different). So I gave up and left that behavior separate. Huh, annoying. Agreed with leaving that alone. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
