some-dbname/some-schema/TABLES/sometable.sql some-dbname/some-schema/VIEWS/someview.sql some-dbname/some-schema/FUNCTIONS/somefunction-param{codes}.sql some-dbname/some-schema/TYPES/sometype.sql some-dbname/some-schema/OPERATORS/OPsomeoperator.sql
In this last, all dependant objects of, for example, a table (rules, triggers,
indexes, etc. ) would be rolled up into one file. It's this last version
that I personally favor.
Not sure I like it from the PoV of easily seeing what has changed.
Similarly:
some-dbname/some-schema/TABLES/sometable/create.sql some-dbname/some-schema/TABLES/sometable/indexes.sql some-dbname/some-schema/TABLES/sometable/constraints.sql
combines all indexes into one file. It also has the disadvantage if being impossible to construct from an existing dump file.
I'd like to be able to construct the structure from the information stored in a dump file, without parsing SQL. OTOH, it might be nice to add some more information to the dump file.
----------------------------------------------------------------
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 |/
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
