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