> > please find a small patch submission so that "pg_restore" ignores some sql
> > errors.
>
> Yeah, we've been talking about doing that for awhile. But please define
> "some errors" --- what do you ignore exactly?
Connection errors are not ignored.
The error is triggered directly by the execute sql function, so it is hard
to know what is going on there. There are 3 instances. I've skipped the
"set session authorization" stuff, but 2 others are filtered.
A more complete implementation would allow to ignore errors on language
restoration or things like that, or initial cleanups... But that would
require to change the current code structure a lot, so as to avoid direct
exits... Moreover it does not look really necessary from my point of view.
I just aim at having direct "pg_restore" behave as "pg_restore|psql".
> + if (AH->n_errors)
> + /* translator: %s stands for "error" or "errors" */
> + fprintf(stderr, _("warning: %d %s ignored on restore\n"),
> + /* translator: in sentence warning: 123 errors
> ignored... */
> + AH->n_errors, AH->n_errors>1? _("errors"): _("error"));
>
> Please read the message style guidelines: the above goes directly
> against the advice for writing translatable messages.
Ok.
> Also, it might be wise to return a nonzero exit code when any errors are
> ignored. I'm not sure about that, but it might be best to err on the
> side of caution...
Ok.
I'll resubmit.
--
Fabien Coelho - [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
