Re: Event Triggers: adding information

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Event Triggers: adding information
Дата
Msg-id 20130118140721.GA29501@alap2.anarazel.de
обсуждение исходный текст
Ответ на Re: Event Triggers: adding information  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Event Triggers: adding information  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > I have no problem requiring C code to use the even data, be it via hooks
> > or via C functions called from event triggers. The problem I have with
> > putting in some hooks is that I doubt that you can find sensible spots
> > with enough information to actually recreate the DDL for a remote system
> > without doing most of the work for command triggers.
> 
> It should be noted that the point of KaiGai's work over the last three
> years has been to solve exactly this problem.  Well, KaiGai wants to
> check security rather than do replication, but he wants to be able
> grovel through the entire node tree and make security decisions based
> on stuff core PG doesn't care about, so in effect the requirements are
> identical.  Calling the facility "event triggers" rather than "object
> access hooks" doesn't make the underlying problem any easier to solve.
>  I actually believe that the object access hook stuff is getting
> pretty close to a usable solution if you don't mind coding in C, but
> I've had trouble convincing anyone else of that.
> 
> I find it a shame that it hasn't been taken more seriously, because it
> really does solve the same problem.  sepgsql, for example, has no
> trouble at all checking permissions for dropped objects.  You can't
> call procedural code from the spot where we've got that hook, but you
> sure can call C code, with the usual contract that if it breaks you
> get to keep both pieces.  The CREATE stuff works fine too.  Support
> for ALTER is not all there yet, but that's because it's a hard
> problem.

I don't have a problem reusing the object access infrastructure at all. I just
don't think its providing even remotely enough. You have (co-)written that
stuff, so you probably know more than I do, but could you explain to me how it
could be reused to replicate a CREATE TABLE?

Problems I see:
- afaics for CREATE TABLE the only hook is in ATExecAddColumn
- no access to the CreateStm, making it impossible to decipher whether e.g. a sequence was created as part of this or
not
- No way to regenerate the table definition for execution on the remote system without creating libpqdump.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Materialized views WIP patch
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: WIP patch for hint bit i/o mitigation