Re: Regression in COPY FROM caused by 9f8377f7a2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Regression in COPY FROM caused by 9f8377f7a2
Date: 2023-09-25 20:52:40
Message-ID: 677f2d81-13b2-6f82-c0b4-4163c753c72f@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
>
>
> On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
>> On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
>>> In v16 and later, the following fails:
>>>
>>> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>>>
>>> COPY boom FROM STDIN;
>>> ERROR:  value too long for type character varying(5)
>>>
>>> In PostgreSQL v15 and earlier, the COPY statement succeeds.
>>>
>>> The error is thrown in BeginCopyFrom in line 1578 (HEAD)
>>>
>>>   defexpr = expression_planner(defexpr);
>>>
>>> Bisecting shows that the regression was introduced by commit 9f8377f7a2,
>>> which introduced DEFAULT values for COPY FROM.
>
>

Thinking about this a little more, wouldn't it be better if we checked
at the time we set the default that the value is actually valid for the
given column? This is only one manifestation of a problem you could run
into given this table definition.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-09-25 21:00:30 Re: SQL:2011 application time
Previous Message Paul Jungwirth 2023-09-25 20:20:59 Re: SQL:2011 application time