Neil Conway <nconway@klamath.dyndns.org> writes:
> Can you elaborate on exactly how you'd like to see COPY's behavior
> changed? What's the rationale for disallowing missing fields in
> COPY input?
Robustness. We've seen problem reports in the past when COPY got out of
sync with the data stream because of loss or insertion of a newline (eg,
due to faulty quoting logic in an application; this scenario is not as
improbable as you might think). Rejecting lines that don't seem to have
the right number of fields would go a long way towards detecting that
sort of mistake. And, since the existing behavior with unexpected
numbers of fields has never been documented, no one feels any strong
compunction about changing it.
This has been hashed out in several prior threads, and in fact I think
Brent Verner has a nearly-ready-to-go patch implementing the agreed-on
behavior. Now that I think about it, your patch is heading off in a
quite different direction from what was agreed to: we were never
intending that omitting trailing fields would be the cue for inserting
default values. Without a way to specify a target column list, that's
far too restrictive; and with it, it's unnecessary.
regards, tom lane
