Re: Coping with 'C' vs 'newC' function language names

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