Skip site navigation (1) Skip section navigation (2)

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

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, josh(at)agliodbs(dot)com,pgsql-bugs(at)postgresql(dot)org, glenniii(at)mail(dot)utexas(dot)edu
Subject: Re: Bug in concat operator for Char? -- More Info
Date: 2004-07-21 16:13:32
Message-ID: 40FE962C.6040206@pse-consulting.de (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

Responses

pgsql-bugs by date

Next:From: Darcy BuskermolenDate: 2004-07-21 19:06:09
Subject: Re: Bug in concat operator for Char? -- More Info
Previous:From: Stephan SzaboDate: 2004-07-21 15:49:38
Subject: Re: Bug in concat operator for Char? -- More Info

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group