Re: Regression in COPY FROM caused by 9f8377f7a2
От | Tom Lane |
---|---|
Тема | Re: Regression in COPY FROM caused by 9f8377f7a2 |
Дата | |
Msg-id | 281733.1695678582@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Regression in COPY FROM caused by 9f8377f7a2 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Regression in COPY FROM caused by 9f8377f7a2
|
Список | 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 по дате отправления: