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
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 |