Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
От | Robert Haas |
---|---|
Тема | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
Дата | |
Msg-id | CA+TgmoZHDoh3PtBooQvRwoRYxUXDzT_bzmEoHeXfYvW+mLPjKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
|
Список | pgsql-hackers |
On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011: > >> Well, it looks to me like there are three different places that we >> need to nail down: RangeVarGetAndCheckCreationNamespace() is used for >> relations (except that a few places call RangeVarGetCreationNamespace >> directly, which means my previous patch probably needs some tweaking >> before commit), QualifiedNameGetCreationNamespace() is used for pretty >> much all other schema-qualified objects, and LookupCreationNamespace() >> is used for ALTER BLAH SET SCHEMA (which I think has a problem when >> you rename an object into a schema that is concurrently being >> dropped). >> >> I'm fairly unhappy with the idea of modifying a function that is >> described as doing a "get" or "lookup" to have the side effect of >> "locking something". So probably some renaming or refactoring is in >> order here. It seems like we're duplicating almost identical logic in >> an awful lot of places in namespace.c. > > So RangeVarGetCheckAndLockCreationNamespace(), uh? Pity you can't > stick a comma in there. Yeah, really. :-) Actually, I think that one could probably stay as-is. "Check" implies that there's something else going on besides just a lookup, and we can't go nuts with it. I'm more concerned about QualifiedNameGetCreationNamespace() and LookupCreationNamespace(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: