Re: ALTER OBJECT any_name SET SCHEMA name - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: ALTER OBJECT any_name SET SCHEMA name
Date
Msg-id m2wrotnoi6.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: ALTER OBJECT any_name SET SCHEMA name  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: ALTER OBJECT any_name SET SCHEMA name
Re: ALTER OBJECT any_name SET SCHEMA name
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
>>     /* check for duplicate name (more friendly than unique-index failure) */
>>     if (SearchSysCacheExists2(TYPENAMENSP,
>>                               CStringGetDatum(name),
>>                               ObjectIdGetDatum(nspOid)))
>
> Hmm, this check is wrong anyway, because you're looking in the pg_type
> syscache for objects from an arbitrary catalog.  That needs to be fixed
> somehow, but perhaps it needs to be handled by the callers, not in this
> routine.  Otherwise you're going to need to pass the syscache ID, as
> well as Datums identifying the object, and the number of Datums.

How embarrassing. I wonder why this works, too:

dim=# alter operator utils.@>(utils.ltree, utils.ltree) set schema public;
ALTER OPERATOR
dim=# alter operator @>(utils.ltree, utils.ltree) set schema utils;
ALTER OPERATOR

We have :

static void
AlterOperatorNamespace_internal(Relation rel, Oid operOid, Oid nspOid)
{
...CheckSetNamespace(oldNspOid, nspOid,                  OperatorRelationId, operOid, NameStr(oprForm->oprname));

Well, I'll go fix as you say, putting the check back into the
callers. That won't help a bit with the code duplication feeling we have
when reading the patch, though. Any idea on this front?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER OBJECT any_name SET SCHEMA name
Next
From: Tom Lane
Date:
Subject: Re: Alter column to type serial