From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Dubious usage of TYPCATEGORY_STRING |
Date: | 2021-12-07 17:19:41 |
Message-ID: | 3500829.1638897581@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 2, 2021 at 4:22 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> An example of the reasons not to treat these types as being
>> general-purpose strings can be seen at [1], where the "char"
>> type has acquired some never-intended cast behaviors. Taking
>> that to an extreme, we currently accept
>>
>> regression=# select '(1,2)'::point::"char";
>> char
>> ------
>> (
>> (1 row)
> 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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-12-07 17:24:36 | Re: Add sub-transaction overflow status in pg_stat_activity |
Previous Message | Robert Haas | 2021-12-07 16:33:38 | Re: pg_dump versus ancient server versions |