Re: ALTER OBJECT any_name SET SCHEMA name
От | Dimitri Fontaine |
---|---|
Тема | Re: ALTER OBJECT any_name SET SCHEMA name |
Дата | |
Msg-id | m2wrotnoi6.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: ALTER OBJECT any_name SET SCHEMA name (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: ALTER OBJECT any_name SET SCHEMA name
Re: ALTER OBJECT any_name SET SCHEMA name |
Список | 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 по дате отправления: