From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [pgsql-patches] pg_get_domaindef |
Date: | 2007-01-24 15:53:31 |
Message-ID: | 45B780FB.4010509@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
[ redirecting discussion to -hackers, where it seems more appropriate ]
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | FAST PostgreSQL | 2007-01-24 16:18:30 | Re: pg_get_domaindef |
Previous Message | Tom Lane | 2007-01-24 15:25:29 | Re: pg_get_domaindef |
From | Date | Subject | |
---|---|---|---|
Next Message | FAST PostgreSQL | 2007-01-24 16:18:30 | Re: pg_get_domaindef |
Previous Message | Tom Lane | 2007-01-24 15:25:29 | Re: pg_get_domaindef |