[v9.2] DROP statement reworks

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема [v9.2] DROP statement reworks
Дата
Msg-id CADyhKSX+ud30gCNnyq16Yhh2=EMkyUtxvvgBvPhjgC8coBcvzg@mail.gmail.com
обсуждение исходный текст
Ответы Re: [v9.2] DROP statement reworks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
The attached three patches try to consolidate code path of DROP
statement on various kind of object classes.

The first part provides a set of internal api to reference properties
of object types; as we had a discussion before.
It adds a big static array indexed by ObjectType; that holds OID of
corresponding catalog, catcache id, attribute number of name,
namespace, owner and so on. Every field of this array is accessable
via get_object_property_*() interfaces.
As a proof-of-concept, I reworked object_exists() with this array to
lookup a heaptuple by the supplied ObjectAddress.

The second part is a revised one from what I submitted in the commit-fest July.
It consolidate existing code paths corresponding to DropStmt (schema,
relations, text searches, type, domain, extension, conversion,
collation).

The third part is more reworks for other object classes (aggregate,
function, language, foreign data wrapper, foreign server, cast,
operator, trigger, rule).

I don't touch on shared database objects (database, tablespace and
role) because its behavior on deletion is not compatible with any
other object classes. So, it is unclear for me whether it is a
suitable case to be consolidated.
And, I also don't touch code corresponding to user-mapping because it
is not supported by get_object_address() yet.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should we have an optional limit on the recursion depth of recursive CTEs?
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: walprotocol.h vs frontends