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 20090125170753.GD11576@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>)
List pgsql-general
On Sun, Jan 25, 2009 at 05:08:54PM +0100, Martijn van Oosterhout wrote:
> On Sun, Jan 25, 2009 at 03:52:02PM +0000, Roger Leigh wrote:
> >
> > 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)?
>
> A function like that exists, the "proper" way to do it is (untested):
>
> DatumGetCString( DirectFunctionCall1(textout, TextGetDatum(foo)  )
>
> It's used in various places, in the unreleased 8.4 there will be
> official functions like cstring_to_text and text_to_cstring. Many other
> modules already declare stuff like this.

Great, it looks like I'll be able to make things much simpler with 8.4,
though I will need to be backward compatible with 8.3 for some time.

> > 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?
>
> Memory leaks are not an issue generally, everything you allocate gets
> freed at the end of the statement, if not earlier. Normally you don't
> manually free at all, however code that might be used by indexes is
> somewhat of an exception, since they might be called often in a tight
> loop. smaller/larger are not index functions, but the cmp function is.
>
> Though your strings here are probably short enough you won't notice
> either way.

Thanks for the clarification, I wasn't aware everything was automatically
freed.  The stricter requirements for index operators does make sense.

> > 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
>
> C++ incompatability has been noted before and patches were posted. I
> don't remember right now what happened to them, check the archives.

Ah, thanks.  I won't file a bug if it's already a known issue.


Thanks again,
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: Thomas Kellerer
Date:
Subject: Re: Resp.: Problem defining deferred check constraints
Next
From: Stephan Szabo
Date:
Subject: Re: Problem defining deferred check constraints