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