Re: recent ALTER whatever .. SET SCHEMA refactoring

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: recent ALTER whatever .. SET SCHEMA refactoring
Дата
Msg-id 20130107191429.GA4368@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: recent ALTER whatever .. SET SCHEMA refactoring  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: recent ALTER whatever .. SET SCHEMA refactoring  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Kohei KaiGai escribió:

> Function and collation are candidates of this special case handling;
> here are just two kinds of object.
>
> Another idea is to add a function-pointer as argument of
> AlterNamespace_internal for (upcoming) object classes that takes
> special handling for detection of name collision.
> My personal preference is the later one, rather than hardwired
> special case handling.
> However, it may be too elaborate to handle just two exceptions.

I think this idea is fine.  Pass a function pointer which is only
not-NULL for the two exceptional cases; the code should have an Assert
that either the function pointer is passed, or there is a nameCacheId to
use.  That way, the object types we already handle in the simpler way do
not get any more complicated than they are today, and we're not forced
to create useless callbacks for objects were the lookup is trivial.  The
function pointer should return boolean, true when the function/collation
is already in the given schema; that way, the message wording is only
present in AlterObjectNamespace_internal.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: [PERFORM] Slow query: bitmap scan troubles
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: psql \l to accept patterns