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()  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Broken SSL tests in master
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Parallel safety of CURRENT_* family