Re: Wrong order of tests in findDependentObjects()
От | Tom Lane |
---|---|
Тема | Re: Wrong order of tests in findDependentObjects() |
Дата | |
Msg-id | 13624.1480626576@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Wrong order of tests in findDependentObjects() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Wrong order of tests in findDependentObjects()
|
Список | pgsql-hackers |
I wrote: >> Jim Nasby <Jim.Nasby@BlueTreble.com> writes: >>> I can't think of any reason you'd want the current behavior. >> But I think fixing it to not recurse to extensions during temp namespace >> cleanup might not be very hard. I'll take a look. I wrote a test case to try to demonstrate that this patch was fixing a bug, and was surprised to find that it didn't fail. The reason turns out to be that we fixed this problem years ago in commit 08dd23cec: Also, arrange for explicitly temporary tables to not get linked as extension members in the first place, and the samefor the magic pg_temp_nnn schemas that are created to hold them. This prevents assorted unpleasant results if anextension script creates a temp table: the forced drop at session end would either fail or remove the entire extension,and neither of those outcomes is desirable. Now, if you really try hard, say by creating a temp function, you can break it. But I don't have all that much sympathy for such use-cases. I think that the patch I wrote is good cleanup, so I'm still inclined to apply it in HEAD, but I no longer think it's fixing any case that's significant in the field. I wonder if you have a counterexample? regards, tom lane
В списке pgsql-hackers по дате отправления: