Re: Coping with 'C' vs 'newC' function language names - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Coping with 'C' vs 'newC' function language names
Date
Msg-id 13388.974304819@sss.pgh.pa.us
Whole thread Raw
In response to Re: Coping with 'C' vs 'newC' function language names  (mlw <markw@mohawksoft.com>)
Responses Re: Coping with 'C' vs 'newC' function language namesh  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
mlw <markw@mohawksoft.com> writes:
> I'm not sure what "NewC" is, nor do I understand what problem it is
> attempting to fix.

I haven't gotten around to updating the main documentation yet (my bad)
but the design document about the fmgr rewrite is in current sources
as src/backend/utils/fmgr/README --- you can read it on the web at
http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README
if you don't have a local copy.

The key issues are summarized in that document as:

: We know that the existing mechanism for calling Postgres functions needs
: to be redesigned.  It has portability problems because it makes
: assumptions about parameter passing that violate ANSI C; it fails to
: handle NULL arguments and results cleanly; and "function handlers" that
: support a class of functions (such as fmgr_pl) can only be done via a
: really ugly, non-reentrant kluge.  (Global variable set during every
: function call, forsooth.)  Here is a proposal for fixing these problems.

To answer another misconception that I saw in this thread:

: The old language names "internal" and "C" will continue to refer to
: functions with the old calling convention.  We should deprecate
: old-style functions because of their portability problems, but the
: support for them will only be one small function handler routine,
: so we can leave them in place for as long as necessary.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: UUNET socket-file-location patch
Next
From: Peter Eisentraut
Date:
Subject: Re: 486 Optimizations...