Re: Regression in COPY FROM caused by 9f8377f7a2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Regression in COPY FROM caused by 9f8377f7a2
Date
Msg-id 281733.1695678582@sss.pgh.pa.us
Whole thread Raw
In response to Re: Regression in COPY FROM caused by 9f8377f7a2  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Regression in COPY FROM caused by 9f8377f7a2
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
>> On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
>>> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');

> 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.

I dunno, it seems at least possible that someone would do this
deliberately as a means of preventing the column from being defaulted.
In any case, the current behavior has stood for a very long time and
no one has complained that an error should be thrown sooner.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix a wrong comment in setrefs.c
Next
From: Peter Eisentraut
Date:
Subject: Re: How to update unicode mapping table?