CREATE TABLE persons (
id        SERIAL      PRIMARY KEY,
firstname TEXT        NOT NULL,
surname   TEXT        NOT NULL,
title     TEXT
);
 
INSERT INTO persons (firstname, surname, title)
  VALUES ('Edward', 'Hyde', NULL);
INSERT INTO persons (firstname, surname, title)
  VALUES ('Henry', 'Jekyll', 'Dr.');
 
SELECT * FROM persons;
 
 id | firstname | surname | title
----+-----------+---------+-------
  1 | Edward    | Hyde    |
  2 | Henry     | Jekyll  | Dr.
(2 rows)
 
SELECT title || ' ' || firstname || ' ' || surname FROM persons;
 
?COLUMN?
------------------
 
Dr. Henry Jekyll
(2 rows)

As you see, the row containing the NULL value is omitted. So how to fix that? Of course we might do something like using COALESCE to return at least an empty string instead of a NULL value, but this way we'd get a whitespace we might not want (on the web not that bad because normaly the browser renders multiple whitespace as one).

So, if you research this issue a bit via google you'll find many solutions. From PL/pgSQL CONCAT functions with might handle two, three or four arguments (CONCAT2, CONCAT3, you get the picture) to solutions using custom aggregate functions. But most of them don't care about NULL values and will break.

Let's try this with a simple CONCAT function:

CREATE OR REPLACE FUNCTION concat(text, text, text) RETURNS text AS $$
SELECT $1 || ' ' || $2 || ' ' || $3;
$$ LANGUAGE 'sql';
 
SELECT CONCAT(title, firstname, surname) FROM persons;
concat
----------------
 
Dr. Henry Jekyll
(2 rows)

Still, the same problem with the row containing the NULL value.

While looking into this, I ran over the buildin function ARRAY_TO_STRING which leads the path to a very straight forward solution:

SELECT ARRAY_TO_STRING(ARRAY[title, firstname, surname], ' ') FROM persons;
 
array_to_string
------------------
Edward Hyde
Dr. Henry Jekyll
(2 rows)

Problem solved!

• we're moving from PostgreSQL 8.1.3 to the 8.3.5
• we're moving from database encoding LATIN1 to UTF8
• in our code we're using the TO_ASCII function a few times.

And this combination produces some headaches.

But first a gentle introduction to the TO_ASCII function. It converts any given text into it's ASCII representation. Folks bound to languages with german umlauts or some kind of apostrophes encounter many problems. For example: what should you do if you have to build some kind of index based on the first character of the lastname. Certainly you don't want to have an extra entry with 'Ü', instead you want to but them into the 'U' list. Grand entrance TO_ASCII:

SELECT to_ascii('Übermeier');
Ubermeie

Works like a charm. Caveat: TO_ASCII only supports LATIN1, LATIN2, LATIN9 and WIN1250 encodings but no UTF8.

Okay, the first guess would be to do something like this:

SELECT to_ascii(convert_to('Übermeier', 'latin1'));
ERROR:  FUNCTION to_ascii(bytea) does NOT exist

Bummer. CONVERT_TO returnes BYTEA, TO_ASCII only wants TEXT.

There has been some discussion going on on the pgsql.hackers mailinglist and frankly I can follow both parties in their point of view. But thanks to Pavel Stehule we have some kind of a hack to sidestep this issue:

CREATE FUNCTION to_ascii(bytea, name)
RETURNS text STRICT AS 'to_ascii_encname' LANGUAGE internal;

This version gladly accepts the BYTEA data returned by CONVERT_TO so we can just use it in this way:

SELECT to_ascii(convert_to('Übermeier', 'latin1'), 'latin1');
Ubermeie

Problem solved.

Edit: Added fix by eMerzh. Thanks!