|From:||Mark Dilger <hornschnorter(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox|
> On Apr 5, 2017, at 9:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
I have written a patch to fix these macro definitions across src/ and contrib/.
Find the patch, attached. All regression tests pass on my Mac laptop.
I don't find any inappropriate uses of _P where _PP would be called for. I do,
however, notice that some datatypes' functions are written to use PG_GETARG_*_P
where PG_GETARG_*_PP might be more efficient. Varbit's bitoctetlength function
could detoast only the header ala PG_DETOAST_DATUM_SLICE to return the
octet length, rather than detoasting the whole thing. But that seems a different
issue, and patches to change that might have been rejected in the past so far as I
know, so I did not attempt any such changes here.
|Next Message||Tom Lane||2017-04-05 20:12:23||Re: PG_GETARG_GISTENTRY?|
|Previous Message||Simon Riggs||2017-04-05 19:42:10||Re: increasing the default WAL segment size|