Re: [HACKERS] Bug or feature? COPY ignores column defaults

"Oliver Elphick" <olly@lfix.co.uk> writes:
>   junk=> copy testbed from stdin;
>   Enter info followed by a newline
>   End with a backslash and a period on a line by itself.
>>> 
>>> \.

> I haven't specified \N; there is no value at all for the column, so
> surely the default should be used?

Oh, I see what you're complaining about.  No, that still shouldn't
mean "substitute the default".  An empty input means an empty string
for text fields.  It MUST NOT mean substitute the default, or you
can't save and reload empty text fields.

I would argue that an empty input field in COPY ought to be a syntax
error for int4 and other types that don't accept an empty string as a
valid external representation.  You ought to be getting something much
like the result of

play=> select '':int4;
ERROR:  parser: parse error at or near ":"
play=> select '':float;
ERROR:  parser: parse error at or near ":"
play=>

(In fact, I'm surprised you're not getting that.  Is COPY ignoring
the complaints from the type conversion routines?)

There's a further issue here, which is that (I assume) you just pressed
return and didn't type the three TAB characters that should have been
required as field separators for your four-column table.  That should've
been a syntax error too, IMHO.

So, I agree COPY has a bug, but not the one you say ;-)
        regards, tom lane