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

Re: Latest on CITEXT 2.0

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Latest on CITEXT 2.0
Date: 2008-06-26 10:28:22
Message-ID: 20080626102822.GB27678@svana.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jun 25, 2008 at 11:47:39AM -0700, David E. Wheeler wrote:
> * There seem to still be some implicit CASTS to text that I'd like to  
> duplicate. For example,  select '192.168.1.2'::cidr::text;` works, but  
> `select '192.168.1.2'::cidr::citext;` does not. Where can I find the C  
> functions that do these casts for TEXT so that I can put them to work  
> for citext, too? The internal cast functions used in the old citext  
> distribution don't exist at all on 8.3.

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.

> * There are casts from text that I'd also like to harness for use by  
> citext, like `cidr(text)`. Where can I find these C functions as well?  
> (The upshot of this and the previous points is that I'd like citext to  
> be as compatible with TEXT as possible, and I just need to figure out  
> how to fill in the gaps in that compatibility.)

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

> * Regular expression and LIKE comparisons using the the operators  
> properly work case-insensitively, but functions like replace() and  
> regexp_replace() do not. Should they? and if so, how can I make them  
> do so?

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

> * As for my C programming, well, what's broken? I'm especially  
> concerned that I pfree variables appropriately, but I'm not at all  
> clear on what needs to be freed. Martijn mentioned before that btree  
> comparison functions free memory, but I'm such a C n00b that I don't  
> know what that actually means for my implementation. I'd actually  
> appreciate a bit of pedantry here. :-)

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.

> * 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.

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog(at)svana(dot)org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-06-26 10:57:07
Subject: Join Removal/ Vertical Partitioning
Previous:From: Simon RiggsDate: 2008-06-26 08:15:13
Subject: Re: Planner creating ineffective plans on LEFT OUTERjoins

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