Re: Custom type, operators and operator class not sorting/indexing correctly

From: Roger Leigh <rleigh(at)codelibre(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Custom type, operators and operator class not sorting/indexing correctly
Date: 2009-01-25 17:07:56
Message-ID: 20090125170753.GD11576@codelibre.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2009-01-25 17:21:59 Re: Problem defining deferred check constraints
Previous Message Thomas Kellerer 2009-01-25 16:10:15 Re: Resp.: Problem defining deferred check constraints