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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
