Re: Custom type, operators and operator class not sorting/indexing correctly - Mailing list pgsql-general

From Roger Leigh
Subject Re: Custom type, operators and operator class not sorting/indexing correctly
Date
Msg-id 20090125155202.GB11576@codelibre.net
Whole thread Raw
In response to Re: Custom type, operators and operator class not sorting/indexing correctly  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Custom type, operators and operator class not sorting/indexing correctly  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
On Wed, Jan 21, 2009 at 08:52:19PM +0100, Martijn van Oosterhout wrote:
> On Wed, Jan 21, 2009 at 10:48:09AM +0000, Roger Leigh wrote:
> > Ah, thanks for the clarification.  So I need to use CREATE TYPE
> > rather than CREATE DOMAIN.  Because I'm essentially just storing
> > a text string with different operators, can I derive a type from
> > TEXT (perhaps by reusing the same input, output, receive and send
> > functions as TEXT?)  I saw the textsend and textreceive functions,
> > which I assume are the appropriate functions for send and receive?
> > Are there any for input and output which I may reuse?
>
> Yes, you can copy all the existing attributes. Use:
>
> select * from pg_type where typname='text';
>
> To get the relevent info (upcoming 8.4 will have CREATE TYPE xxx
> (LIKE=text) ). Lookup the citext project for an example.

Many thanks for this suggestion; it has been incredibly useful.
Using a pre-existing C implementation, plus looking at citext for
how to write the operators correctly, I now have a working pure
C (C++ implementation).


http://git.debian.org/?p=users/rleigh/sbuild.git;a=tree;f=db;h=0a6d3348744c59b78322ec6a4855876875613239;hb=81fd39259953853632a7d0e2198cfc745d270fe3

I just have a few points I'd like to clarify.  In


http://git.debian.org/?p=users/rleigh/sbuild.git;a=blob;f=db/debversion.cc;h=980786ecf7a3b7fb5769d04b0952af300723c3b9;hb=81fd39259953853632a7d0e2198cfc745d270fe3

debversioncmp (lines 49-73), I'm duplicating text* to char* by hand.
Is the text_to_cstring available internally also accessible by
external modules (I didn't see it in any headers)?

After every PG_GETARG_TEXT_PP, I've called PG_FREE_IF_COPY before
returning.  However, I saw in citext (the behaviour of which I
duplicated in debversion_smaller and debversion_larger (lines 221-246))
that you *don't* use PG_FREE_IF_COPY before returning one of the two
values.  Is this not a potential memory leak?  Don't you need to
duplicate your chosen value, then free both of the temporary values?

I also noticed that I couldn't include some postgres headers in
my code (e.g. <access/builtins.h>) due to included headers
<nodes/parsenodes.h> and <nodes/primnodes.h> using invalid C++ syntax
due to use of "using" and "typename" which are reserved C++ keywords.
The headers are also not wrapped with extern "C" blocks for direct
inclusion in C++ sources, though this isn't as big a deal--you can
just include them as I did within such a block in your own code.
The former problem can't be worked around due to it being invalid
code (this can be rectified by renaming to not use these specific
keyword names).


Many thanks for your help,
Roger

--
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment

pgsql-general by date:

Previous
From: Osvaldo Kussama
Date:
Subject: Resp.: Problem defining deferred check constraints
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Custom type, operators and operator class not sorting/indexing correctly