Re: Dubious usage of TYPCATEGORY_STRING - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dubious usage of TYPCATEGORY_STRING
Date
Msg-id CA+TgmoaACz=dMA21y6VEANw9HLVVDbE9Z0hPnPxXWPaE1--XTQ@mail.gmail.com
Whole thread Raw
In response to Re: Dubious usage of TYPCATEGORY_STRING  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 7, 2021 at 12:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > What's wrong with that?
>
> Well, we don't allow things like
>
> regression=# select '(1,2)'::point::float8;
> ERROR:  cannot cast type point to double precision
> LINE 1: select '(1,2)'::point::float8;
>                              ^
>
> It's not very clear to me why "char" should get a pass on that.
> We allow such cases when the target is text/varchar/etc, but
> the assumption is that the textual representation is sufficient
> for your purposes.  It's hard to claim that just the first
> byte is a useful textual representation.

Fair enough, I guess. I am pretty skeptical of the merits of refusing
an explicit cast. If I ran the zoo, I would probably choose to allow
all such casts and make them coerce via IO when no other pathway is
available. But I get that's not our policy.

> Worse, PG is actually treating this as an assignment-level cast,
> so we accept this:
>
> regression=# create table t(f1 "char");
> CREATE TABLE
> regression=# insert into t values ('(1,2)'::point);
> INSERT 0 1
> regression=# table t;
>  f1
> ----
>  (
> (1 row)
>
> I definitely don't think that should have worked without
> any complaint.

Yes, that one's a bridge too far, even for me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Transparent column encryption
Next
From: Tom Lane
Date:
Subject: Re: ExecTypeSetColNames is fundamentally broken