Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt
От | Alvaro Herrera |
---|---|
Тема | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt |
Дата | |
Msg-id | 1309972002-sup-3858@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to
handle DropStmt
|
Список | pgsql-hackers |
Excerpts from Robert Haas's message of mié jul 06 12:40:39 -0400 2011: > This patch removes an impressive amount of boilerplate code and > replaces it with something much more compact. I like that. In the > interest of full disclosure, I suggested this approach to KaiGai at > PGCon, so I'm biased: but even so, I'm pleasantly surprised by the > amount of consolidation that appears possible here. Yeah. Myself, I love the fact that the dropmsgstrings thing is gone. I wonder if the routine to obtain "foo doesn't exist, skipping" messages could be replaced by judicious use of getObjectDescription. > Here, we're essentially duplicating that information in another > place, which doesn't seem good. I think perhaps we should create a > big static array, each row of which would contain: > > - ObjectType > - system cache ID for OID lookups > - system catalog table OID for scans > - attribute number for the name attribute, where applicable (see > AlterObjectNamespace) > - attribute number for the namespace attribute > - attribute number for the owner attribute > - ...and maybe some other properties +1 for this general approach. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: