Philip Warner wrote:
+ if (strcmp(te->desc,"CONSTRAINT") == 0
||
+ strcmp(te->desc,"FK
CONSTRAINT") == 0 ||
+ strcmp(te->desc,"CHECK
CONSTRAINT") == 0 ||
+ strcmp(te->desc,"TRIGGER") == 0
||
+
strcmp(slots[i].te->desc,"CONSTRAINT") == 0 ||
+ strcmp(slots[i].te->desc,"FK
CONSTRAINT") == 0 ||
+ strcmp(slots[i].te->desc,"CHECK
CONSTRAINT") == 0 ||
+
strcmp(slots[i].te->desc,"TRIGGER") == 0)
Really just an observation from the peanut gallery here, but every time
pg_restore hard-codes this kind of thing, it introduces yet another
possible side-effect bug when someone, eg, adds a new TOC type.
Would it substantially decrease the benefits of the patch to skip *any*
toc entry that shares dependencies with another? (rather than just those
listed above).
Unfortunately, it quite possibly would. You would not be able to build
two indexes on the same table in parallel, even though they wouldn't
have conflicting locks.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
