Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types. - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.
Date
Msg-id CAFjFpRftz53XBD=cagxdN_1FiOL_gSGegO9jO7VjR0PnNN9uAg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.
List pgsql-hackers
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?

The patch does that when creating a view with constant literals, which
are known to be binary compatible with text and hence coercible. It
looks like any "unknown' type data should be coercible to text, so it
shouldn't matter whether those are constants or non-constant nodes.

>
>> You might want to add some testcases to test the error report e.g.
>> (not necessarily in the same form) create view sv as select
>> relname::unknown from pg_class;
>> ERROR:  column "relname" has type "unknown"
>
>                         regards, tom lane



-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries