Re: Latest on CITEXT 2.0

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.