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 по дате отправления: