From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Updated COPY CSV patch |
Date: | 2004-04-13 12:38:18 |
Message-ID: | 20040413123818.GA10378@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Tue, Apr 13, 2004 at 06:58:24 -0400,
Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> One area that we should think about as an enhancement is NOT NULL fields.
> As it stands now, we will get what we normally get when we try to insert
> a null into a NOT NULL field, namely an error. If the field has a simple
> literal default we could force that. And in the special case of
> text/varchar fields, it would be reasonable to force an empty string even
> if no default is set. There isn't a nice easy answer, I'm afraid. We
> shouldn't hold up putting this in on that account, but handling this
> better is certainly a TODO.
If you try to insert NULLs into a nonnull field you should get an error.
If you have unquoted empty strings, and are not using the empty string as
the NULL marker, then you can just not set the NULL code to be the empty
string. If you need to turn this on and off by column, then perhaps it
would be better to do that externally.
As for setting default values, I think that is a good idea. I suggested
a while back. There could be another keyword, DEFAULT, on the COPY FROM
command that is used to define a code that will be replaced by the
default value (or NULL if there is no default for a column) similar to
how the NULL code is replaced by NULL.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-04-13 14:18:53 | Re: Updated COPY CSV patch |
Previous Message | Andrew Dunstan | 2004-04-13 11:32:19 | Re: Updated COPY CSV patch |