Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
Date
Msg-id 1565.1149963483@sss.pgh.pa.us
Whole thread Raw
In response to TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> So could I get some further definition?

There are two fairly strong reasons for NOT trying to push more logic
into the backend from pg_dump:

1. It would remove the freedom we currently have to make pg_dump adapt
dumps from old servers to match newer syntax/semantics.  This has saved
our bacon more than once in the past, so it shouldn't be given up
lightly.

2. The backend functions invariably read the catalogs under SnapshotNow
rules, making pg_dump unable to promise a consistent snapshot to the
extent that it relies on them.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [PATCHES] ADD/DROP INHERITS
Next
From: Tom Lane
Date:
Subject: Re: How to avoid transaction ID wrap