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

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

From: Isaac Jurado <ijurado(at)econcept(dot)es>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6185: Segmentation fault with NULL string columns
Date: 2011-08-30 18:53:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Tue, Aug 30, 2011 at 8:21 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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.

I figured that 5 minutes after reporting.  I tried to sent a reply email
but it seems it didn't arrive.  Thanks anyway.

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

The default to_ascii expects a string as a first argument.  As our DB
encoding is UTF8 we need to filter everything through
convert_to(..., 'LATIN1').  Because convert_to function returns a
"bytea" type, we cannot use to_ascii in vanilla flavour.

We are not too fond with the PostgreSQL specifics (although the explicit
::text cast didn't work), so we found that function definition on a
wiki and it worked.

But now, unless you know a more correct way to do it, it works like a
charm by appending "STRICT" to the function definition.

Best regards and sorry for the noise.

Isaac Jurado
Internet Busines Solutions eConcept

In response to

pgsql-bugs by date

Next:From: Isaac JuradoDate: 2011-08-30 18:54:44
Subject: Re: BUG #6185: Segmentation fault with NULL string columns
Previous:From: Heikki LinnakangasDate: 2011-08-30 18:35:32
Subject: Re: BUG #6186: out of memory while analyze

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