Re: || operator

2014-09-03 15:25 GMT+02:00 Szymon Guz <mabewlun(at)gmail(dot)com>:

>
>
>
> On 3 September 2014 15:20, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>> Hi
>>
>> you can define || operator for char(N) type
>>
>> postgres=# select oprname, oprleft::regtype, oprright::regtype from
>> pg_operator where oprname = '||'
>> ;
>> oprname | oprleft | oprright
>> ---------+-------------+-------------
>> || | bytea | bytea
>> || | text | text
>> || | text | anynonarray
>> || | bit varying | bit varying
>> || | anyarray | anyarray
>> || | anyarray | anyelement
>> || | anyelement | anyarray
>> || | anynonarray | text
>> || | tsvector | tsvector
>> || | tsquery | tsquery
>> (10 rows)
>>
>>
>> it is defined only for text, and value char(n) is reduced when it is
>> converted probably
>>
>> postgres=# create or replace function concat_character(character,
>> character) returns text as $$ select concat($1,$1)$$ language sql;
>> CREATE FUNCTION
>>
>> postgres=# create operator || (procedure = concat_character, leftarg =
>> character, rightarg = character);
>> CREATE OPERATOR
>> postgres=# select 'abc '::char(7) || 'dbe '::char(6);
>> ?column?
>> ----------------
>> abc abc
>> (1 row)
>>
>> concat is variadic "any" function, so implicit casting character(n) ->
>> text is not used there
>>
>>
>> Pavel
>>
>>
>
> Hi Pavel,
> I think we should have this in core, as this definitely is a bug.
>

hard to say - anything about CHAR(N) is strange, and this change can break
existing applications :(

I remember one previous CHAR(N) issue, and probably it was not fixed too.

I have not any opinion, just I don't know

Pavel

>
> Szymon
>