Peter Eisentraut <pete...@gmx.net> writes:
> On tis, 2011-08-30 at 18:07 -0400, Tom Lane wrote:
>> Yeah, we've been around on that before. pg_dump does actually sort the
>> output items (modulo dependency requirements), but it sorts by the same
>> "tag" values that are printed by pg_restore -l, and those aren't currently
>> designed to be unique. It's not too clear if we could get away with
>> changing the definitions of the tag strings.
> It's a bit strange that the tag for a trigger is "name" but the tag for
> the trigger's comment is "name ON table". Not having the table name in
> the trigger tag sounds wrong, because it makes the tag not very useful
> for selecting the trigger from the TOC.
I don't think changing that would be a problem. What gets unpleasant is
trying to guarantee that pg_dump object tags are unconditionally unique.
That would, for example, mean that every argument type of every function
would have to be written out fully-schema-qualified.
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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
