Re: Should PG backend know how to represent metadata?

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 |/