Joshua D. Drake wrote:
> Tom Lane wrote:
> > "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.
>
>
> O.k. color me stupid but what does what you said above have in any way
> to do with what the requirements for these functions are?
>
> Maybe I am misunderstanding the TODO (which is entirely possible due to
> the complete lack of documentation on the feature) but I *thought* all I
> was going to do was create 6 functions that could be called to get
> various useful information?
>
> For example, pg_get_tabledef() would be a very handy function to use for
> just about any abstracted API. As it stands now most (like Pear) create
> their own custom queries/functions to handle it but they are more often
> then not very innefficient.
I thought the TODO item was exactly what you described:
* %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(),
pg_get_functiondef()
We have per-server-version checks in pg_dump, so I figured the idea was
to use more of those functions if the exist, like we do now. It is true
that you can't modify them for old versions as easily as you can if they
are hardcoded in pg_dump, but we our existing functions seems to work
fine.
-- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
