Renaming PG_GETARG functions (was Re: PG_GETARG_GISTENTRY?)

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?)
Date: 2017-09-12 20:07:35
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

[ 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
> contrib/.

So to summarize, this patch proposes to rename some DatumGetFoo,
PG_GETARG_FOO, and PG_RETURN_FOO macros for these datatypes:

NDBOX (contrib/cube)
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

In response to


Browse pgsql-hackers by date

  From Date Subject
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