On 08/31/2011 10:17 AM, Tom Lane wrote:
> Short of that sort of anal-retentiveness, there are going to be cases
> where the dump order is a bit unpredictable. IMO what we need is a
> reasonable compromise between verbosity and uniqueness, such that in
> normal cases (ie, where you *didn't* intentionally create near-identical
> functions in different schemas) you get a unique ordering. To get to
> that, somebody's got to go through all the tag writing code and identify
> where the trouble spots are. So far we've heard triggers and operators
> nominated ... what else?
So far, for Pyrseas, I've tested aggregates, casts, constraint triggers,
conversions, domains, functions, indexes, languages, operators, rules,
schemas, sequences, tables (including check constraints, primary keys,
foreign keys, unique constraints and inherited tables), triggers, types
(base and composite), views and comments on the various objects. I'll
be testing operator classes and operator families in the coming weeks.
So far, triggers and operators are the only ones that have caused an
issue when using the technique suggested by Jaime (pg_dump -Fc followed
by pg_restore -l). Functions also caused problems in the plain text
pg_dump, e.g., because funcx(geography) sorts after funcx(geometry) if
the latter is created first.
Joe
