At 17:06 17/07/00 +1000, Philip Warner wrote:
>
>Suggestion:
>
>I would envisage the API consisting of a custom dump routine for each
>object type. In the case of the table dumper API, it would return a table
>definition with no indexes or constraints and a list of related entities
>consisting of (object-type, object-oid) pairs suitable for passing back to
>the dumper API. psql could display as little or as much as it desired,
>pg_dump could ferret the extra items away for later use etc. For those
>items that can not be separated out, then they obviously have to go into
>the main definition.
>
Just took the dog for a walk, and had another thought. If we really want
this to have the maximum usability, then we should make it available from SQL.
ie.
select pg_dump('table', 'foo')
where pg_dump returns (possibly) multiple rows, the first being the most
basic definition, and subsequent rows being additional items & their
name/id, eg:
'Create Table Foo(Bar int);" NULL
'index' 'foo_ix1'
'constraint' 'foo_pk'
etc.
I don't think we have functions that return multiple rows, and a 'select'
without a 'from' is not strictly legal, but aside from that, an SQL-based
solution mught be a nice idea. Which brings me to my next idea:
select defn from pg_dump where type='table and name = 'foo'
or select related_items from pg_dump where type='table and name = 'foo'
where pg_dump can be implemented via a rewrite rule....maybe.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
