Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types. |
Дата | |
Msg-id | CAB7nPqQKiQZszLsNv9J=7y8riQZa=CN0JV_t5KSNcYGPkuuNQQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types. (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.
|
Список | pgsql-hackers |
On Fri, Dec 30, 2016 at 1:30 PM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > On Thu, Dec 29, 2016 at 8:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes: >>> The way this patch has been written, it doesn't allow creating tables >>> with unknown type columns, which was allowed earlier. >> >> Yes, that's an intentional change; creating such tables (or views) has >> never been anything but a foot-gun. >> >> However, I thought the idea was to silently coerce affected columns from >> unknown to text. This doesn't look like the behavior we want: > > Do you mean to say that when creating a table with a column of unknown > type, that column type should be silently converted (there's nothing > to coerce when the table is being created) to text? instead of > throwing an error? FWIW that's what I understood: the patch should switch unknown columns to text. A bunch of side effects when converting types are avoided this way. -- Michael
В списке pgsql-hackers по дате отправления: