Re: [GENERAL] Large databases, performance - Mailing list pgsql-performance

From Shridhar Daithankar
Subject Re: [GENERAL] Large databases, performance
Date
Msg-id 3DA47F4D.12909.1AAA876E@localhost
Whole thread Raw
In response to Re: [GENERAL] Large databases, performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On 9 Oct 2002 at 9:32, Tom Lane wrote:

> Manfred Koizar <mkoi-pg@aon.at> writes:
> > here is an implementation of a set of user types: char3, char4,
> > char10.
>
> Coupla quick comments on these:
>
> > CREATE FUNCTION charNN_lt(charNN, charNN)
> >     RETURNS boolean
> >     AS '$libdir/fixchar'
> >     LANGUAGE 'c';
>
> > bool
> > charNN_lt(char *a, char *b)
> > {
> >     return (strncmp(a, b, NN) < 0);
> > }/*charNN_lt*/
>
> These functions are dangerous as written, because they will crash on
> null inputs.  I'd suggest marking them strict in the function
> declarations.  Some attention to volatility declarations (isCachable
> or isImmutable) would be a good idea too.

Let me add something. Using char* is bad idea. I had faced a situation recently
on HP-UX 11 that with a libc patch, isspace collapsed for char>127. Fix was to
use unsigned char. There are other places also where the input character is
used as index to an array internally and can cause weird behaviour for values
>127

I will apply both the correction here. Will post the final stuff soon.

Bye
 Shridhar

--
Hacker's Quicky #313:    Sour Cream -n- Onion Potato Chips    Microwave Egg Roll
Chocolate Milk


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Large databases, performance
Next
From: Robert Treat
Date:
Subject: Re: What does this tell me?