|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Mark Dilger <hornschnorter(at)gmail(dot)com>|
|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>|
|Subject:||Renaming PG_GETARG functions (was Re: PG_GETARG_GISTENTRY?)|
|Views:||Raw Message | Whole Thread | Download mbox|
[ changing subject line to possibly draw more attention ]
Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Apr 5, 2017, at 9:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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);
> I have written a patch to fix these macro definitions across src/ and
So to summarize, this patch proposes to rename some DatumGetFoo,
PG_GETARG_FOO, and PG_RETURN_FOO macros for these datatypes:
LTREE and other contrib/ltree types
PG_GETARG_ANY_ARRAY (and there are some related macros it maybe should
have touched, like PG_RETURN_EXPANDED_ARRAY)
The contrib types don't seem like much of a problem, but I wonder
whether anyone feels that rationalizing the names for array, JSON,
or range-type macros will break too much code.
One option if we do feel that way is that we could provide the
old names as alternatives, thus not breaking external modules.
But that seems like it's sabotaging the basic goal of improving
consistency of naming.
If there are not objections, I plan to push forward with this.
regards, tom lane
|Next Message||Chapman Flack||2017-09-12 20:12:00||Re: Faster methods for getting SPI results|
|Previous Message||Robert Haas||2017-09-12 19:52:54||Re: domain type smashing is expensive|