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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Coping with 'C' vs 'newC' function language names
Дата
Msg-id 13388.974304819@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Coping with 'C' vs 'newC' function language names  (mlw <markw@mohawksoft.com>)
Ответы Re: Coping with 'C' vs 'newC' function language namesh  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: UUNET socket-file-location patch
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: 486 Optimizations...