Re: || operator

[Pavel Stehule <pavel.stehule@xxxxxxxxx>]

2014-09-03 15:25 GMT+02:00 Szymon Guz <mabewlun@xxxxxxxxx>:

On 3 September 2014 15:20, Pavel Stehule <pavel.stehule@xxxxxxxxx> 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