Re: Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...)

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...)
Date: 2018-06-26 04:02:35
Message-ID: CAA4eK1JokY7O7AuRa5F2v97GbdOB+dV=uHQ9VjB-mYcB_Ykj0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 15, 2018 at 9:46 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jun 15, 2018 at 12:54 AM, Andrew Dunstan
> <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>>
>> On 06/14/2018 02:01 PM, Alvaro Herrera wrote:
>>>
>>> We used to use prefixes for common struct members names to help
>>> disambiguate across members that would otherwise have identical names in
>>> different structs. Our convention was to use _ as a separator. This
>>> convention has been partially lost, but seems we can use it to good
>>> effect here, by renaming ammissingPresent to am_present and ammissing to
>>> am_missing (I would go as far as suggesting am_default or am_substitute
>>> or something like that).
>>
>> am_present and am_value perhaps? I'm not dogmatic about it.
>>
>
> +1. Attached patch changed the names as per suggestion.
>
>>
>>
>>
>>> BTW I think "the result stored" is correct English.
>>>
>>
>> Yes, it certainly is.
>>
>
> Okay.
>
> How about attached?
>

Andrew, Alvaro, do you think we can go ahead with above naming
suggestions or do we want to brainstorm more on it?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rui DeSousa 2018-06-26 04:04:59 Re: automatic restore point
Previous Message Isaac Morland 2018-06-26 03:01:06 Re: automatic restore point