Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id 1321298707-sup-8007@alvh.no-ip.org
Whole thread Raw
In response to Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List pgsql-hackers
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.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: strict aliasing (was: const correctness)
Next
From: Thom Brown
Date:
Subject: Re: patch: CHECK FUNCTION statement