Re: [HACKERS] Text <-> C string

From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Text <-> C string
Date: 2007-10-01 19:20:12
Message-ID: 37ed240d0710011220w5d49c3e6u89d814a9f1578df9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely useful set of functions to convert between text
and C string in the backend.

The new extern functions, declared in include/utils/builtins.h and
defined in backend/utils/adt/varlena.c, are:

char * text_cstring(const text *t)
char * text_cstring_limit(const text *t, int len)
text * cstring_text(const char *s)
text * cstring_text_limit(const char *s, int len)

Within varlena.c, the actual conversions are performed by:

char * do_text_cstring(const text *t, const int len)
text * do_cstring_text(const char *s, const int len)

These functions now do the work for the fmgr functions textin and
textout, as well as being directly accessible by backend code.

I've searched through the backend for any code which converted between
text and C string manually (with memcpy and VARDATA), replacing with
calls to one of the four new functions as appropriate.

I came across some areas which were using the same, or similar,
conversion technique on other varlena data types, such as bytea or
xmltype. In cases where the conversion was completely identical I
used the new functions. In cases with any differences (even if they
seemed minor) I played it safe and left them alone.

I'd now like to submit my work so far for review. This patch compiled
cleanly on Linux and passed all parallel regression tests. It appears
to be performance-neutral based on a few rough tests; I haven't tried
to profile the changes in detail.

There is still a lot of code out there using DirectFunctionCall1 to
call text(in|out)). I've decided to wait for some community feedback
on the patch as it stands before replacing those calls. There are a
great many, and it would be a shame to have to go through them more
than once.

I would naively expect that replacing fmgr calls with direct calls
would lead to a performance gain (no fmgr overhead), but honestly I'm
not sure whether that would actually make a difference.

Thanks for your time,
BJ

Attachment Content-Type Size
text-cstring_1.diff.gz application/x-gzip 9.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-10-01 19:59:16 Re: First steps with 8.3 and autovacuum launcher
Previous Message Simon Riggs 2007-10-01 18:54:48 Re: PG on NFS may be just a bad idea

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2007-10-01 20:34:24 Re: OpenSSL Applink
Previous Message richard 2007-10-01 17:27:37 Patch to inline stable SQL set returning UDFs