Lists: | pgsql-bugs |
---|
From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..) |
Date: | 2014-11-14 16:40:36 |
Message-ID: | CAKuK5J1WQX_dt8pF4zfmvyH79gC9suT46seo92prJOHAYMq-WQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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?
--
Jon
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..) |
Date: | 2014-11-14 17:59:18 |
Message-ID: | 31008.1415987958@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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.
regards, tom lane
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 |
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
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in,..) |
Date: | 2015-03-20 21:13:02 |
Message-ID: | 20150320211302.GT6317@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Fri, Nov 14, 2014 at 01:12:37PM -0600, Jon Nelson wrote:
> 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.
Patch attached for review.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachment | Content-Type | Size |
---|---|---|
btree_gin.diff | text/x-diff | 1.6 KB |
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in,..) |
Date: | 2015-03-25 00:53:42 |
Message-ID: | 20150325005341.GE19256@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Fri, Mar 20, 2015 at 05:13:02PM -0400, Bruce Momjian wrote:
> On Fri, Nov 14, 2014 at 01:12:37PM -0600, Jon Nelson wrote:
> > 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.
>
> Patch attached for review.
Patch applied.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in, ..) |
Date: | 2015-03-26 23:02:12 |
Message-ID: | CAKuK5J3vyCvT5h9wcQ5uoR4MR4OCOfOw48a-j_wyM9SiuPtMjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Fri, Mar 20, 2015 at 4:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Fri, Nov 14, 2014 at 01:12:37PM -0600, Jon Nelson wrote:
>> 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.
>
> Patch attached for review.
For as much as it's worth, I did review the patch and it looks just perfect.
--
Jon
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: minor: contrib/btree_gin/btree_gin.c uses DirectFunctionCall3(inet_in,..) |
Date: | 2015-03-31 14:27:18 |
Message-ID: | 20150331142718.GA4466@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Thu, Mar 26, 2015 at 06:02:12PM -0500, Jon Nelson wrote:
> On Fri, Mar 20, 2015 at 4:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Fri, Nov 14, 2014 at 01:12:37PM -0600, Jon Nelson wrote:
> >> 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.
> >
> > Patch attached for review.
>
> For as much as it's worth, I did review the patch and it looks just perfect.
Patch applied. Thanks for the report.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +