| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
| Date: | 2021-06-26 08:20:11 |
| Message-ID: | alpine.DEB.2.22.394.2106261015070.482873@pseudo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Yugo-san,
>> I'm wondering whether we could use "vars" instead of "variables" as a
>> struct field name and function parameter name, so that is is shorter and
>> more distinct from the type name "Variables". What do you think?
>
> The struct "Variables" has a field named "vars" which is an array of
> "Variable" type. I guess this is a reason why "variables" is used instead
> of "vars" as a name of "Variables" type variable so that we could know
> a variable's type is Variable or Variables. Also, in order to refer to
> the field, we would use
>
> vars->vars[vars->nvars]
>
> and there are nested "vars". Could this make a codereader confused?
Hmmm… Probably. Let's keep "variables" then.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-06-26 10:13:25 | Re: Doc chapter for Hash Indexes |
| Previous Message | Michael Banck | 2021-06-26 08:17:52 | Failover messages in Timeline History |