Re: BUG #6185: Segmentation fault with NULL string columns

On 30.08.2011 11:51, Isaac Jurado wrote:
>
> The following bug has been logged online:
>
> Bug reference:      6185
> Logged by:          Isaac Jurado
> Email address:      ijurado@econcept.es
> PostgreSQL version: 8.4.8
> Operating system:   Ubuntu 10.04.03 LTS (x86_64)
> Description:        Segmentation fault with NULL string columns
> Details:
>
> Here's the script to make it fail:
>
> CREATE DATABASE killme;
> \c killme
> CREATE FUNCTION to_ascii(bytea, name) RETURNS text AS 'to_ascii_encname'
> LANGUAGE internal;
> CREATE TABLE mytable (id INTEGER PRIMARY KEY, mytext TEXT);
> INSERT INTO mytable (id, mytext) VALUES (1, '');
> SELECT * FROM mytable WHERE to_ascii(convert_to(mytext, 'latin1'), 'latin1')
> = to_ascii(convert_to('nicetry', 'latin1'), 'latin1');
> UPDATE mytable SET mytext=NULL WHERE id=1;
> SELECT * FROM mytable WHERE to_ascii(convert_to(mytext, 'latin1'), 'latin1')
> = to_ascii(convert_to('nicetry', 'latin1'), 'latin1');
>
> After the second query, the database server segfaults.  Note that it only
> fails for NULL values.  The to_ascii/convert_to combination is a recipe for
> diacritics elimination found on a PostgreSQL forum.

to_ascii_encname is marked as STRICT, which means that it returns NULL
on NULL input, without ever calling the underlying C function. The
"to_ascii" function that you created is not marked as STRICT, so the
to_ascii_encname C function is called on NULL input. It's not prepared
for that, and crashes, because it's not supposed to be called on NULL input.

Why do you create your own 'internal' language function like that in the
first place? Just use the existing to_ascii function.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com