On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
> > #define TextPGetCString(t)
> > DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(t)))
> > #define CStringGetTextP(c) DatumGetTextP(DirectFunctionCall1(textin,
> > CStringGetDatum(c)))
> I think if you look around you'll find several similar things in various
> contrib modules.  It would make some sense to try to unify all this.
> I'm not particularly for making it macros in postgres.h though ---
> that's no help if the macros require referencing stuff in builtins.h.
> On grounds of code-space savings I think it might be worth making
> these things be simple functions declared in builtins.h; that would
> also make it much easier to change their implementations.

You're right about finding similar things in various places.  Even
varlena.c has a set of these macros (PG_TEXT_GET_STR etc), but it
doesn't look they've really been utilised.

I'm happy to take a swing at this.  Declaring in builtins.h makes sense.

The thing that's got me confused at the moment is what naming
convention to use for the functions.  Looking in builtins.h you might
get the impression that we use lower_underscore for functions that are
called via fmgr, UPPER_UNDERSCORE for macros and CamelCase for
ordinary internal C functions, but there are plenty of exceptions to
disprove that rule.  I see camel cased macros and lowercased internal
functions.  Camel cased identifiers sometimes start with uppercase,
sometimes lowercase.

So the name for the text -> cstring function could be any of:


Is there any kind of authoritative naming convention I can refer to?

Thanks for your time,

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to