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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-06-26 10:57:07 | Join Removal/ Vertical Partitioning |
Previous Message | Simon Riggs | 2008-06-26 08:15:13 | Re: Planner creating ineffective plans on LEFT OUTER joins |