2014-09-03 15:25 GMT+02:00 Szymon Guz <mabew...@gmail.com>: > > > > On 3 September 2014 15:20, Pavel Stehule <pavel.steh...@gmail.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 >
