Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: Digital signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux