From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
cc: Robert Haas <robertmhaas@gmail.com>,
	Dimitri Fontaine <dimitri@2ndquadrant.fr>,
	Simon Riggs <simon@2ndquadrant.com>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
In-reply-to: <20130118170857.GK29501@alap2.anarazel.de>
References: <16675.1358454278@sss.pgh.pa.us> <m2hamfcwc8.fsf@2ndQuadrant.fr>
	<18941.1358462151@sss.pgh.pa.us> <m2ehhjbf48.fsf@2ndQuadrant.fr>
	<20130118013334.GE3074@awork2.anarazel.de>
	<CA+TgmobU2xZ7hPh24HYmvSxO7kbXUtY57bePX+mpB5aywTz2HA@mail.gmail.com>
	<20130118140721.GA29501@alap2.anarazel.de>
	<CA+TgmoYL9o2MBjWdaUcRqj_B5J=k63rq8vKkcszDyH4CDT1AKQ@mail.gmail.com>
	<20130118154732.GE29501@alap2.anarazel.de>
	<CA+Tgmoa-p-texRBzgetFgvaKwWJJ=a3XBCWMOQdg17aWtrDPNg@mail.gmail.com>
	<20130118170857.GK29501@alap2.anarazel.de>
Comments: In-reply-to Andres Freund <andres@2ndquadrant.com>
	message dated "Fri, 18 Jan 2013 18:08:57 +0100"
Date: Fri, 18 Jan 2013 12:44:13 -0500
Message-ID: <10183.1358531053@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
>> I'm having trouble following this.  Can you restate?  I wasn't sure
>> what you meant by libpqdump.  I assumed you were speaking of a
>> parsetree->DDL or catalog->DDL facility.

> Yea, that wasn't really clear, sorry for that.

> What I was trying to say that I think doing parstree->text conversion
> out of tree is noticeably more complex and essentially places a higher
> maintenance burden on the project because

Ah.  That's not pg_dump's job though, so you're choosing a bad name for
it.  What I think you are really talking about is extending the
deparsing logic in ruleutils.c to cover utility statements.  Which is
not a bad plan in principle; we've just never needed it before.  It
would be quite a lot of new code though.

An issue that would have to be thought about is that there are assorted
scenarios where we generate "parse trees" that contain options that
cannot be generated from SQL, so there's no way to reverse-list them
into working SQL.  But often those hidden options are essential to know
what the statement will really do, so I'm not sure ignoring them will be
a workable answer for replication purposes.

			regards, tom lane


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