Re: pg_dump as a bunch of PostgreSQL functions

At 06:00 PM 14/09/2004, Mark Gibson wrote:
>I have an idea, to break pg_dump into functions within PostgreSQL.

This has been suggested before, and I think been generally accepted as the
right broad approach (the basic idea that the pg backend should know how to
describe itself).

Recent versions of pg_dump have started using backend functions to dump
database structures (eg. type definitions). As time goes by more functions
will be written, but I don't think it's the highest priority on anybody's
list. There are also the information schemas which are the ISO way of
getting database definitions; these can/should be used where possible.

However, there are some complications because pg_dump is also the upgrade
tool; the backed can only know how to describe itself for the current
dialect of SQL accepted by PG. As we upgrade and improve the SQL, and add
features, pg_dump needs to talk to old backends and dump prior versions in
a format compatible with current (new) versions. This means that for some
purposes it will not be able to use backend functions, or at least will
have to have it's own mutant version of them.

There are other differences; for reasons of performance and atomicity, we
try to keep the items dumped as simple as possible. eg. in 8.0, a table
definition will ultimately be dumped as:

1. set default_tablespace=xxx
1. set search_path=xxx
2. create table (no constraints, tablespace or namespace clauses)
4. load table data
3. alter table add constraint...
5. set table acls

A 'friendly' definition would at least contain the namespace & constraints,
but pg_dump does not want that.

So it's not a simple as it sounds.

<random_idea>
Perhaps it would be nice if, in each new version we created a library that
could be built against old versions to provide the functions needed by
pg_dump to upgrade, and a similar library would form part of the new
version as well. Kind of a 'pg_dump translation plugin'. This may be way
too expensive an option, when a few 'if' statements inside pg_dump will
achieve almost the same result. It would remove/reduce bloat in pg_dump and
make the functions available more generally, at the expense of duplicating
lots of code for each supported version.
</random_idea>

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/