Re: pg_dump as a bunch of PostgreSQL functions - Mailing list pgsql-hackers

From Philip Warner
Subject Re: pg_dump as a bunch of PostgreSQL functions
Date
Msg-id 6.1.2.0.0.20040914224724.05d44ba0@203.8.195.10
Whole thread Raw
In response to pg_dump as a bunch of PostgreSQL functions  (Mark Gibson <gibsonm@cromwell.co.uk>)
List pgsql-hackers
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       |/ 



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Why are there client-only encodings?
Next
From: Tom Lane
Date:
Subject: Re: Why are there client-only encodings?