Re: Command Triggers

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Command Triggers
Дата
Msg-id 877h21ww7a.fsf@hi-media-techno.com
обсуждение исходный текст
Ответ на Re: Command Triggers  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Yeah.  I remember mentioning the ability of CREATE SCHEMA to embed all
> sort of object creation commands in a single top-level command, and
> being handwaved away by Jan.  "Nobody knows about that", I was told.

In fact CREATE SCHEMA implementation will fire a process utility command
per element, see src/backend/commands/schemacmds.c:122
 * Execute each command contained in the CREATE SCHEMA.  Since the grammar * allows only utility commands in CREATE
SCHEMA,there is no need to pass * them through parse_analyze() or the rewriter; we can just hand them * straight to
ProcessUtility.

> However, if this is to work in a robust way, these things should not be
> ignored.  In particular, firing triggers on each top-level command _is_
> going to get some objects ignored; the people writing the triggers _are_
> going to forget to handle CREATE SCHEMA properly most of the time.

My current thinking is that the tool as proposed in the patch is useful
enough now already, and that we should cover its limitations in the
documentation.  And also be somehow verbose about the nodeToString()
output where to find almost all you need.

Down the road, we might decide that either what we've done is covering
enough needs (after all, we managed not to have the features for years)
or decide to have internal commands implementation (create index from
inside a create table statement, say) go through ProcessUtility.

Also note that currently, anyone motivated enough to write a
ProcessUtility hook (in C) will face the same problem here, the hook
will not get called for any event where the command trigger would not
get called either.

So while I understand your concerns here, I think they are rather
theoretical, as we can already add support for create table, alter
table, and drop table to slony, londiste and bucardo with the existing
patch, and also implement create extension whitelisting and allow
non-superuser to install selected C coded extensions.

FWIW, those are the two main use cases I'm after.

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


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

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] Fix Leaky View Problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is anybody actually using XLR_BKP_REMOVABLE?