Re: COPY and default values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: COPY and default values
Date: 2002-05-27 23:28:30
Message-ID: 28505.1022542110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Neil Conway <nconway(at)klamath(dot)dyndns(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-05-27 23:36:08 Re: SSL (patch 1)
Previous Message Neil Conway 2002-05-27 23:10:53 Re: COPY and default values