From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG_GETARG_GISTENTRY? |
Date: | 2017-04-05 16:23:02 |
Message-ID: | 20373.1491409382@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-05 16:26:25 | Re: partitioned tables and contrib/sepgsql |
Previous Message | Robert Haas | 2017-04-05 16:22:45 | Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |