Обсуждение: Re: PG_GETARG_GISTENTRY?
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
> On Apr 5, 2017, at 9:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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 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. Mark Dilger
Вложения
Mark Dilger <hornschnorter@gmail.com> writes: > 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. Thanks for doing the legwork on that. This seems a bit late for v10, especially since it's only cosmetic, but please put it in the first v11 commitfest. > 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. Yeah. I think Noah did some work in that direction already, but I don't believe he claimed to have caught everything. Feel free to push further. regards, tom lane
> On Apr 5, 2017, at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: >> 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. > > Thanks for doing the legwork on that. You are welcome. > This seems a bit late for v10, > especially since it's only cosmetic Agreed. > , but please put it in the first > v11 commitfest. Done. > >> 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. > > Yeah. I think Noah did some work in that direction already, but I don't > believe he claimed to have caught everything. Feel free to push further. Thanks for clarifying.