RE: [Proposal] Level4 Warnings show many shadow vars

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема RE: [Proposal] Level4 Warnings show many shadow vars
Дата
Msg-id MN2PR18MB2927AC54B8F6CB0F74BB31CDE35B0@MN2PR18MB2927.namprd18.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [Proposal] Level4 Warnings show many shadow vars  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
De: Alvaro Herrera <alvherre@2ndquadrant.com>
Enviado: segunda-feira, 9 de dezembro de 2019 22:06

>I find this choice a bit ugly and even more confusing than the original.
>I'd change this to be just "segsize".
Ok.

>I would tend to name the GUC variable as if it were a global in the
>sense that I proposed in my previous response (ie. WalSegmentSize), but
>that creates a bit of a problem when one greps the source looking for
>reference to the GUCs.  Some GUCs do have CamelCase names and others
>don't; I've grown fond of the current style of using the same name for
>the variable as for the GUC itself, for grepping reasons.  So I'm not
>going to propose to do that.  But let's not make a function parameter
>have a name that vaguely suggests that it itself is a GUC.
I understand the ease of grepping.
But ideally, having global names that by convention would make it very clear that they are global, something like:
pg_conn or gconn or guc_synch_commit
The prefix does not matter, as long as once all the new variables and the ones that might have to be changed were
chosen,they adopted the agreed nomenclature. 
That way, when looking for global names, it would be easy.

>Here I propose to rename the global instead (to WalReceiverConn maybe).
>There's nothing about the name "wrconn" that suggests it's a global
>variable.  In any other place where the object is used as a local
>variable, I'd just use "conn".  Trying to be clever and adding a letter
>here or a letter there makes it *more* likely that you'll reference the
>wrong one in some function.
Again, it could be that name, WalReceiverConn, but nothing in it suggests it is a global one.
For a project that makes extensive use of globals, it would help to have a nomenclature defined at least for the
prefix:
pg_WalReceiverConn or gWalReceiverConn and if it is a guc, guc_WalReceiverConn?

>I don't agree with this change very much.  I think "progname" in
>particular is a bit of a debacle right now but I don't think this is the
>best fix.  I'd leave this alone.
Ok. In such cases, it doesn't hurt today. But for future reasons, it would be better to fix everything, imo.

>As before: let's rename the file-level static instead.  "sentPtr" is not
>a good name.
gsent_Ptr or pg_sentPtr?

regards,
Ranier Vilela


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeevan Chalke
Дата:
Сообщение: Re: backup manifests
Следующее
От: Suraj Kharage
Дата:
Сообщение: Re: backup manifests