Re: Dubious usage of TYPCATEGORY_STRING

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Dubious usage of TYPCATEGORY_STRING
Дата
Msg-id 3500829.1638897581@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Dubious usage of TYPCATEGORY_STRING  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Dubious usage of TYPCATEGORY_STRING  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 2, 2021 at 4:22 PM Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_dump versus ancient server versions
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Add sub-transaction overflow status in pg_stat_activity