Re: recent ALTER whatever .. SET SCHEMA refactoring
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2013-01-15T14:56:08Z
Lists: pgsql-hackers
Kohei KaiGai escribió: > 2013/1/15 Alvaro Herrera <alvherre@2ndquadrant.com>: > > Alvaro Herrera escribió: > >> Kohei KaiGai escribió: > >> > >> > I'm probably saying same idea. It just adds invocation of external > >> > functions to check naming conflicts of functions or collation; that > >> > takes additional 4-lines for special case handling > >> > in AlterObjectNamespace_internal(). > >> > >> Okay, I can agree with this implementation plan. > > > > Actually, now that I look again, this is all completely broken, because > > the "object already exists in schema foo" message is using > > getObjectDescription infrastructure, which we agree to be completely > > wrong. > > > http://www.postgresql.org/message-id/CADyhKSWVqaA6iF5wVuW5EzLaiYyCYEE2zO9guqNKy8FRdLx5Gw@mail.gmail.com > > Does this patch help the trouble? > It adds ereport_on_namespace_conflict() for error message generation instead of > getObjectDescription() for ALTER RENAME primarily, but I also noticed it can be > applied on getObjectDescription() of AlterObjectNamespace_internal. I was just going to look into that patch, thanks. Anyway I noticed that the getObjectDescriptionOids() in that path has been there since 9.1 introduced generic object support for SET SCHEMA in 55109313. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services