Re: recent ALTER whatever .. SET SCHEMA refactoring - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: recent ALTER whatever .. SET SCHEMA refactoring
Date
Msg-id 20130115145608.GD4146@alvh.no-ip.org
Whole thread Raw
In response to Re: recent ALTER whatever .. SET SCHEMA refactoring  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List 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



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: [PATCH] COPY .. COMPRESSED
Next
From: Alvaro Herrera
Date:
Subject: Re: ALTER command reworks