Re: Tentative patch for making DROP put dependency info in DETAIL
От | Alvaro Herrera |
---|---|
Тема | Re: Tentative patch for making DROP put dependency info in DETAIL |
Дата | |
Msg-id | 20080610142247.GB5198@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Tentative patch for making DROP put dependency info in DETAIL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Tentative patch for making DROP put dependency info in DETAIL
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: