Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..)

From: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..)
Date: 2014-11-14 19:12:37
Message-ID: CAKuK5J3QZpMr+5=2yGqgRCyFSCp8-nAfFJx593A7Zkiqe7k2wQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Nov 14, 2014 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
>> contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in,..)
>> instead of DirectFunctionCall1(inet_in, one_argument).
>
>> That doesn't seem right. Does such a thing matter?
>
> It's not really incorrect: in a call going through InputFunctionCall(),
> which is the normal path, the two extra arguments would be provided
> whether the specific datatype input function needed them or not.
>
> However, I think the usual convention for DirectFunctionCall() usage
> is to pass exactly what the target function uses, since you know
> exactly what you're calling. Certainly that's what happens in the
> two direct calls to inet_in in the core code.
>
> So I tend to agree that we should change this call to match the others,
> but it's purely cosmetic.

So, are there any additional steps that you might recommend that I take?
It's such a trivial thing. I could provide a patch, of course, or a
pull request off of github if people use that.

--
Jon

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-11-14 22:21:19 Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true
Previous Message Tom Lane 2014-11-14 17:59:18 Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..)