Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> 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/
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
