Re: Dubious usage of TYPCATEGORY_STRING

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Dubious usage of TYPCATEGORY_STRING
Date: 2021-12-07 15:51:46
Message-ID: 3495177.1638892306@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 02.12.21 22:22, Tom Lane wrote:
>> My first thought about fixing point 1 was to put "char" into some
>> other typcategory, but that turns out to break some of psql's
>> catalog queries, with results like:
>>
>> regression=# \dp
>> ERROR: operator is not unique: unknown || "char"
>> LINE 16: E' (' || polcmd || E'):'
>> ^
>> HINT: Could not choose a best candidate operator. You might need to add explicit type casts.

> Could we add explicit casts (like polcmd::text) here? Or would it break
> too much?

I assumed it'd break too much to consider doing that. But I suppose
that since a typcategory change would be initdb-forcing anyway, maybe
it's not out of the question. I'll investigate and see exactly how
many places would need an explicit cast.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-12-07 15:52:42 Re: types reliant on encodings [was Re: Dubious usage of TYPCATEGORY_STRING]
Previous Message Peter Eisentraut 2021-12-07 15:48:21 Re: Dubious usage of TYPCATEGORY_STRING