Skip site navigation (1) Skip section navigation (2)

Re: Event Triggers: adding information

From: Steve Singer <ssinger(at)ca(dot)afilias(dot)info>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers: adding information
Date: 2013-01-27 17:08:33
Message-ID: 51055F11.6040208@ca.afilias.info (view raw or flat)
Thread:
Lists: pgsql-hackers
On 13-01-26 11:11 PM, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
> <dimitri(at)2ndquadrant(dot)fr> wrote:
>> My understanding is that if the command string we give to event triggers
>> is ambiguous (sub-object names, schema qualifications, etc), it comes
>> useless for logical replication use. I'll leave it to the consumers of
>> that to speak up now.
>
> Yeah, that's probably true.  I think it might be useful for other
> purposes, but I think we need a bunch of infrastructure we don't have
> yet to make logical replication of DDL a reality.
>

I agree.  Does anyone have a specific use case other than DDL 
replication where an ambiguous command string would be useful? Even for 
use cases like automatically removing a table from replication when it 
is dropped, I would want to be able to determine which table is being 
dropped unambiguously. Could I determine that from an oid? I suspect so, 
but parsing a command string and then trying to figure out the table 
from the search_path doesn't sound very appealing.

> Well, the point is that if you have a function that maps a parse tree
> onto an object name, any API or ABI changes can be reflected in an
> updated definition for that function.  So suppose I have the command
> "CREATE TABLE public.foo (a int)".  And we have a call
> pg_target_object_namespace(), which will return "public" given the
> parse tree for the foregoing command.  And we have a call
> pg_target_object_name(), which will return "foo".  We can whack around
> the underlying parse tree representation all we want and still not
> break anything - because any imaginable parse tree representation will
> allow the object name and object namespace to be extracted.  Were that
> not possible it could scarcely be called a parse tree any longer.

How do you get the fully qualified type of the first column?
col1=pg_target_get_column(x, 0)
pg_target_get_type(col1);

or something similar.

I think that could work but we would be adding a lot of API functions to 
get all the various bits of info one would want the API to expose. I 
also suspect executing triggers that had to make lots of function calls 
to walk a tree would be much slower than an extension that could just 
walk the parse-tree or some other abstract tree like structure.

Steve


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-27 17:11:53
Subject: Re: autovacuum not prioritising for-wraparound tables
Previous:From: Robert HaasDate: 2013-01-27 17:04:34
Subject: Re: Enabling Checksums

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group