Re: Comment update in BuildTupleFromCStrings()

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Comment update in BuildTupleFromCStrings()
Date: 2018-04-04 03:38:57
Message-ID: CAFjFpRetsDMEfxhVe24sxqSCnTYnsjkvKo3T4Nh5eA9cQfYqZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks Bruce.

On Tue, Apr 3, 2018 at 11:31 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Fri, Mar 23, 2018 at 03:00:37PM +0530, Ashutosh Bapat wrote:
>> Hi,
>> BuildTupleFromCStrings() has comment "/* Call the "in" function for
>> each non-dropped attribute */". It then calls the in function even
>> when it's going to set that attribute to NULL.
>> 1189 if (!TupleDescAttr(tupdesc, i)->attisdropped)
>> 1190 {
>> 1191 /* Non-dropped attributes */
>> 1192 dvalues[i] = InputFunctionCall(&attinmeta->attinfuncs[i],
>> 1193 values[i],
>> 1194 attinmeta->attioparams[i],
>> 1195 attinmeta->atttypmods[i]);
>> 1196 if (values[i] != NULL)
>> 1197 nulls[i] = false;
>> 1198 else
>> 1199 nulls[i] = true;
>> 1200 }
>>
>> If we are setting isnull to true i.e. it's a NULL value, dvalues
>> value doesn't matter but we still invoke corresponding in function,
>> which looks strange and the comment doesn't help. But there's code in
>> make_tuple_from_result_row() which does the same thing and explain why
>> we need to invoke in() function even on the NULL values. I thought,
>> the same comment applies here. Here's patch to update the comment in
>> BuildTupleFromCStrings().
>
> Patch applied.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + As you are, so once was I. As I am, so you will be. +
> + Ancient Roman grave inscription +

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-04 04:00:13 Re: [HACKERS] path toward faster partition pruning
Previous Message David Rowley 2018-04-04 03:21:06 Re: [HACKERS] path toward faster partition pruning