Message-ID: <45B780FB.4010509@dunslane.net>
Date: Wed, 24 Jan 2007 10:53:31 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.8.0.6) Gecko/20060804 Fedora/1.0.4-0.5.1.fc5 SeaMonkey/1.0.4
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: FAST PostgreSQL <fastpgs@fast.fujitsu.com.au>,
	Neil Conway <neilc@samurai.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [pgsql-patches] pg_get_domaindef
References: <12753.10901169180733.fast.fujitsu.com.au@MHS>
	<22604.10061169615735.fast.fujitsu.com.au@MHS>
	<45B76AE7.3090308@dunslane.net> <482.1169652329@sss.pgh.pa.us>
In-Reply-To: <482.1169652329@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


[ redirecting discussion to -hackers, where it seems more appropriate ]

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> FAST PostgreSQL wrote:
>>     
>>> Please find attached the patch with modifications
>>>       
>
>   
>> are you proposing to implement the other functions in this TODO item 
>> (pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), 
>> pg_get_tabledef(), pg_get_functiondef() ) ?
>>     
>
> I haven't entirely understood the use case for any of these.  It's not
> pg_dump, for a number of reasons: one being that pg_dump still has to
> support older backend versions, and another being that every time we
> let backend SnapshotNow functions get involved, we take another hit to
> pg_dump's claim to produce a consistent MVCC snapshot.
>
> But my real objection is: do we really want to support duplicative code
> in both pg_dump and the backend?  Updating pg_dump is already a major
> PITA whenever one adds a new feature; doubling that work isn't
> attractive.  (And it'd be double, not just a copy-and-paste, because of
> the large difference in the operating environment.)  So I want to hear a
> seriously convincing use-case that will justify the maintenance load we
> are setting up for ourselves.  "Somebody might want this" is not
> adequate.
>
> Perhaps a better area of work would be the often-proposed refactoring of
> pg_dump into a library and driver program, wherein the library could
> expose individual functions such as "fetch the SQL definition of this
> object".  Unfortunately, that'll be a huge project with no payoff until
> the end...
>
> 	
>   

I agree entirely. I'm not sure how big the refactoring would be, but I 
do think it's a good goal. Neil mentioned something about it the other day.

It is a worry though that we have an item on the TODO list that has been 
worked on and now we might say "Thanks, but no thanks". That's not a 
good way to make friends for PostgreSQL. This is why I think we need the 
TODO list to be somewhat authoritative, i.e. a list of things that we 
have some sort of consensus about doing and commitment to accepting, at 
least in principle.

cheers

andrew