Re: parallel pg_restore - WIP patch
| От | Philip Warner |
|---|---|
| Тема | Re: parallel pg_restore - WIP patch |
| Дата | |
| Msg-id | 48E19C48.7010402@rhyme.com.au обсуждение |
| Ответ на | Re: parallel pg_restore - WIP patch (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: parallel pg_restore - WIP patch
|
| Список | pgsql-hackers |
> > + 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).
В списке pgsql-hackers по дате отправления: