Re: PG_GETARG_GISTENTRY?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PG_GETARG_GISTENTRY?
Дата
Msg-id 20373.1491409382@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: PG_GETARG_GISTENTRY?
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> we have a good number of '(GISTENTRY *) PG_GETARG_POINTER(n)' in our
>>> code - looks a bit better & shorter to have PG_GETARG_GISTENTRY(n).

>> Should be PG_GETARG_GISTENTRY_P to match existing conventions,
>> otherwise +1

> I have never quite understood why some of those macros have _P or _PP
> on the end and others don't.

_P means "pointer to".  _PP was introduced later to mean "pointer to
packed (ie, possibly short-header) datum".  Macros that mean to fetch
pointers to pass-by-ref data, but aren't using either of those naming
conventions, are violating project conventions, not least because you
don't know what they're supposed to do with short-header varlena input.
If I had a bit more spare time I'd run around and change any such macros.

In short, if you are supposed to write
FOO  *val = PG_GETARG_FOO(n);

then the macro designer blew it, because the name implies that it
returns FOO, not pointer to FOO.  This should be
FOO  *val = PG_GETARG_FOO_P(n);
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: partitioned tables and contrib/sepgsql