Re: || versus concat( ), diff behavior - Mailing list pgsql-general

From Philip Couling
Subject Re: || versus concat( ), diff behavior
Date
Msg-id 4F513FBE.2040303@pedal.me.uk
Whole thread Raw
In response to || versus concat( ), diff behavior  (<david.sahagian@emc.com>)
Responses Re: || versus concat( ), diff behavior  ("David Johnston" <polobo@yahoo.com>)
List pgsql-general
On 02/03/12 20:58, david.sahagian@emc.com wrote:
> Can anybody please point me to where this "difference of behavior" is explained/documented ?
> Thanks,
> -dvs-
>
> -- version = 9.1.3
> do $$
> declare
>    v_str  char(10);
> begin
>    v_str := 'abc' ;
>    raise info '%', concat(v_str, v_str) ;
>    raise info '%', v_str||v_str ;
> end
> $$;
>
> INFO:  abc       abc
> INFO:  abcabc
>
>

Concat is a function which concatenates whatever you give it blindly.
Hence it has the behavior that includes the blanks.

The || operator reflects the more general PostgreSQL principle that
trailing blanks are insignificant for char fields.  You see the same
behavior when comparing char variables.


This can be found in the manual:

http://www.postgresql.org/docs/current/static/datatype-character.html

Values of type character are physically padded with spaces to the
specified width n, and are stored and displayed that way. However, the
padding spaces are treated as semantically insignificant. Trailing
spaces are disregarded when comparing two values of type character, and
they will be removed when converting a character value to one of the
other string types. Note that trailing spaces are semantically
significant in character varying and text values, and when using pattern
matching, e.g. LIKE, regular expressions.


Hope this makes it just a little clearer.

Regards

pgsql-general by date:

Previous
From: Ben Chobot
Date:
Subject: Re: || versus concat( ), diff behavior
Next
From: Piyush Lenka
Date:
Subject: Restoring selected records from backup file