Re: Bug in concat operator for Char? -- More Info

Tom Lane wrote:

> Food for thought: in 7.4,
>
> regression=# select ('X '::char) = ('X'::char);
> ?column?
> ----------
> t
> (1 row)
>
> regression=# select ('Y '::char) = ('Y'::char);
> ?column?
> ----------
> t
> (1 row)
>
> regression=# select ('X '::char || 'Y '::char) = ('X'::char || 'Y'::char);
> ?column?
> ----------
> t
> (1 row)
>
> If we change || as is proposed in this thread, then the last case would
> yield 'false', because the first concatenation would yield 'X Y '
> which is not equal to 'XY' no matter what you think about trailing
> spaces. I find it a bit disturbing that the concatenation of equal
> values would yield unequal values.

Well this indicates that the first two examples are questionable. 'X '
is quite-the-same as 'X', but not really-the-same.

CREATE OR REPLACE FUNCTION toms_name() RETURNS char(50)
as $BODY$
DECLARE fullname char(50);
DECLARE firstname char(50) := 'Tom';
DECLARE secondname char(50) := 'G';
DECLARE lastname char(50) := 'Lane';
BEGIN
fullname := firstname;
IF secondname != '' THEN
IF fullname != '' THEN
fullname := fullname || ' ';
END IF;
fullname := fullname || secondname;
END IF;
IF fullname != '' THEN
fullname := fullname || ' ';
END IF;
fullname := fullname || lastname;

RETURN fullname;
END;
$BODY$ LANGUAGE 'plpgsql'

I find the result of this function quite surprising, and certainly not
yielding what was intended (yes, this can avoided, I know). Surprise is
getting bigger, if fullname is declared as text...

> IMHO the bottom line here is that the SQL-spec behavior of type char(N)
> is completely brain-dead.

Just for COBOL's sake, I suppose.

Regards,
Andreas