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.
?
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
=== The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency:
+1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
