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

Re: Latest on CITEXT 2.0

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Latest on CITEXT 2.0
Date: 2008-06-26 15:27:36
Message-ID: 5F9B80BA-0389-4B64-B402-E0AB8863EC0C@kineticode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun 26, 2008, at 03:28, Martijn van Oosterhout wrote:

> Hmm, casts to/from text are somewhat "magic" in postgres. They are
> implemented by calling the usual type input/output function. I have no
> idea how to extend that to other types.

Oh. Okay. Perhaps I won't worry about it just now, then.

> As above, they're probably not as seperate functions but a special  
> hack
> inthe casting code.

Okay.

> Regexes have case-insensetive modifiers, don't they? In which case I
> don't think it'd be becessary.

They do, but replace(), split_part(), strpos(), and translate() do not.

> When creating an index, your comparison functions are going ot be
> called O(N log N) times. If they leak into a context that isn't
> regularly freed you may have a problem. I'd suggest loking at how the
> text comparisons do it. PG_FREE_IF_COPY() is probably a good idea
> because the incoming tuples may be detoasted.

Okay. I'll have a look at varlena.c, then.

>> * Am I in fact getting an appropriate nul-terminated string in my
>> cilower() function using this code?
>>
>>    char * str  = DatumGetCString(
>>        DirectFunctionCall1( textout, PointerGetDatum( arg ) )
>>    );
>
> Yes.

Great, I thought so (since it made the failures go away). Many thanks.

David


In response to

pgsql-hackers by date

Next:From: Chris BrowneDate: 2008-06-26 15:31:34
Subject: Re: Planner creating ineffective plans on LEFT OUTER joins
Previous:From: KaiGai KoheiDate: 2008-06-26 15:20:58
Subject: Re: Proposal of SE-PostgreSQL patches [try#2]

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