Mark Dilger 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.
Pushed after some rebasing and some minor additional editorialization.
The original point
On Mon, Apr 24, 2017 at 09:25:25AM -0700, Mark Dilger wrote:
> Here is a small patch for the next open commitfest which handles a case
> that Noah's commits 9d7726c2ba06b932f791f2d0cc5acf73cc0b4dca and
> 3a0d473192b2045cbaf997df8437e7762d34f3ba apparently missed.
The scope for those commits was
> On Apr 5, 2017, at 1:27 PM, Mark Dilger wrote:
>
>
>> On Apr 5, 2017, at 1:12 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> I have written a patch to fix these macro definitions across src/ and
>>> contrib/.
>>>
> On Apr 5, 2017, at 1:12 PM, Tom Lane wrote:
>
> Mark Dilger 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
Mark Dilger 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
> On Apr 5, 2017, at 9:23 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane wrote:
>>> Andres Freund writes:
we have a good number of '(GISTENTRY *)
Robert Haas writes:
> On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane wrote:
>> Andres Freund writes:
>>> we have a good number of '(GISTENTRY *) PG_GETARG_POINTER(n)' in our
>>> code - looks a bit better & shorter to have
On Wed, Mar 29, 2017 at 11:54 PM, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
regards, tom
Hi,
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).
Arugments against?
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
10 matches
Mail list logo