Re: parallel pg_restore - WIP patch - Mailing list pgsql-hackers

From Philip Warner
Subject Re: parallel pg_restore - WIP patch
Date
Msg-id 48E19C48.7010402@rhyme.com.au
Whole thread Raw
In response to Re: parallel pg_restore - WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: parallel pg_restore - WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Next
From: Andrew Dunstan
Date:
Subject: Re: parallel pg_restore - WIP patch