> This brings up a related issue, the fact that a dump file does NOT look
> like the origenal script that made the database, that is things like
> SERIAL, PRIMARY KEY, REFERENCES table (field), VIEW, and probably some
> other things that I missed, none of these things are reconstruced in the
> dump file in any intuative way.
>
> All these things can be done in a more round about, more obtuse way, but
> the whole point of them (seems to me any way) is to make the source file
> easier to read and understand. Am I off base here? if so then what is the
> point?
>
> So, working off the last point, should not the dump file, aside from it's
> data, look like the origanal script that made the database? so if a table
> has a PRIMARY KEY, then instead of an index at the bottom of the dump
> file, the table should have ... PRIMARY KEY... in it.
>
> The main reasones I use such constructs are 1. readability and 2.
> convienance. As relates to a dump file, #1 is lost and #2 does not
> matter, unless maybe one wants to hand edit the dump file for some
> reason.
I don't think we want to make the dump look like the script that created. The
dump is setup to reload the database quickly. That is why the tables and
sequences are created first, then the data is inserted into the tables and
finally the indexes are added last. If we make dump look like the database
script, then the dump-reload will take considerably longer.
I do not have any emperical data at this time to show the above is true, but I
can gather some if someone is interested in it.
-Ryan
P.S. I'm working on a pro's and con's list for the sequences.. then I'm planning
on implimenting a few different options and see what everyone prefers. Not sure
when I'll have this done, this project has become more complex then I first
imagined :)