pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Steve Singer <ssinger@ca.afilias.info>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
Date: Sun, 27 Jan 2013 12:08:33 -0500
Message-ID: <51055F11.6040208@ca.afilias.info> (raw)
In-Reply-To: <CA+TgmoZ4U6Bwe-+HhUFWaj2fhG5S=Wo5zK5KR0x7RyU9qphKAQ@mail.gmail.com>
References: <m2txrsdzxa.fsf@2ndQuadrant.fr>
	<m2bodi55yn.fsf@2ndQuadrant.fr>
	<CA+TgmoZTxXGAkoyQD0aNOyju1X19SnVfk7KV9fsJCv63bS-C4g@mail.gmail.com>
	<m27go1ot1a.fsf@2ndQuadrant.fr>
	<20130104205251.GB9191@alvh.no-ip.org>
	<m28v88pqin.fsf@2ndQuadrant.fr>
	<20130109165829.GB4490@alvh.no-ip.org>
	<CA+TgmobykpymdGyfbCDEfS6+-50X-AKYTdK88fjMS4-mY5SBdw@mail.gmail.com>
	<m2ehhkrfqk.fsf@2ndQuadrant.fr>
	<CA+TgmobfeB_YpgMv5NjW52tG36Hg_DY=jq0XDkE5zwCstPQ4pg@mail.gmail.com>
	<m2pq14m7sx.fsf@2ndQuadrant.fr>
	<CA+TgmoYEW583z+oisToCYQMz2grzpavdXrCi3-W2D_+nucVhzQ@mail.gmail.com>
	<m2k3rbhh79.fsf@2ndQuadrant.fr>
	<CA+TgmoZYFhn=DyenBLr8KUZXYHtgjo-O8YE-7y61WKR6F05UQA@mail.gmail.com>
	<m21udesaz3.fsf@2ndQuadrant.fr>
	<CA+TgmoYimdGCiKFbKFbcZ_pJ5jT+sryxN40p24i8efq8j6BNgA@mail.gmail.com>
	<m2k3r27tej.fsf@2ndQuadrant.fr>
	<CA+TgmoZz6MXQ5zX6dopc_xaHVkdwhEhgDFJeAWsRNs+N7e_ueA@mail.gmail.com>
	<m238xptd28.fsf@2ndQuadrant.fr>
	<CA+TgmoZ4U6Bwe-+HhUFWaj2fhG5S=Wo5zK5KR0x7RyU9qphKAQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 13-01-26 11:11 PM, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
> <dimitri@2ndquadrant.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (114+ messages)  latest in thread

Message-ID: <51055F11.6040208@ca.afilias.info>
Permalink:  ../51055F11.6040208@ca.afilias.info/
Also on:    postgresql.org/message-id/51055F11.6040208@ca.afilias.info

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: ssinger@ca.afilias.info, robertmhaas@gmail.com, dimitri@2ndquadrant.fr, andres@anarazel.de, alvherre@2ndquadrant.com
  Subject: Re: Event Triggers: adding information
  In-Reply-To: <51055F11.6040208@ca.afilias.info>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox