Unix Technical Forum

Re: [pgsql-patches] pg_get_domaindef

This is a discussion on Re: [pgsql-patches] pg_get_domaindef within the pgsql Hackers forums, part of the PostgreSQL category; --> [ redirecting discussion to -hackers, where it seems more appropriate ] Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-12-2008, 07:37 AM
Andrew Dunstan
 
Posts: n/a
Default Re: [pgsql-patches] pg_get_domaindef


[ 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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 10:04 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com