Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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: text-cstring_1.diff.gz
Description: application/x-gzip (9.8 KB)

In response to

Responses

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group