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: