boolean and bool in documentation

On Tue, Feb 19, 2019 at 12:56:19AM +0900, Masahiko Sawada wrote:

AFAICS there seems not to be explicit rules and policies for usage of
'boolean' and 'bool'. We use 'bool' for colum data type of almost
system catalogs but use 'boolean' for some catalogs (pg_pltemplate and
pg_policy). The same is true for functions and system views. Is it
better to unify them into 'boolean' for consistency and so as not
unnecessarily confuse users? FYI the name of boolean type is 'boolean'
in the standard.

Yes, I think so.

--
Bruce Momjian <bruce@momjian.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 +

Bruce Momjian <bruce@momjian.us> writes:

On Tue, Feb 19, 2019 at 12:56:19AM +0900, Masahiko Sawada wrote:

AFAICS there seems not to be explicit rules and policies for usage of
'boolean' and 'bool'. We use 'bool' for colum data type of almost
system catalogs but use 'boolean' for some catalogs (pg_pltemplate and
pg_policy). The same is true for functions and system views. Is it
better to unify them into 'boolean' for consistency and so as not
unnecessarily confuse users? FYI the name of boolean type is 'boolean'
in the standard.

Yes, I think so.

FWIW, I'm not excited about this. We accept "bool" and "boolean"
interchangeably, and it does not seem like an improvement for the
docs to use only one form. By that argument, somebody should go
through the docs and nuke every usage of "::" in favor of
SQL-standard CAST(...) notation, every usage of "float8"
in favor of DOUBLE PRECISION, every usage of "timestamptz" in
favor of the long form, etc etc.

regards, tom lane

On Thu, Feb 21, 2019 at 7:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

FWIW, I'm not excited about this. We accept "bool" and "boolean"
interchangeably, and it does not seem like an improvement for the
docs to use only one form. By that argument, somebody should go
through the docs and nuke every usage of "::" in favor of
SQL-standard CAST(...) notation, every usage of "float8"
in favor of DOUBLE PRECISION, every usage of "timestamptz" in
favor of the long form, etc etc.

I'm not terribly excited about it either, but mostly because it seems
like a lot of churn for a minimal gain, and it'll be consistent for
about 6 months before somebody re-introduces a conflicting usage. I
do not, on the other hand, believe that there's no point in being
consistent about anything unless we're consistent about everything;
that's a straw man.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Feb 21, 2019 at 7:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

FWIW, I'm not excited about this. We accept "bool" and "boolean"
interchangeably, and it does not seem like an improvement for the
docs to use only one form. By that argument, somebody should go
through the docs and nuke every usage of "::" in favor of
SQL-standard CAST(...) notation, every usage of "float8"
in favor of DOUBLE PRECISION, every usage of "timestamptz" in
favor of the long form, etc etc.

I'm not terribly excited about it either, but mostly because it seems
like a lot of churn for a minimal gain, and it'll be consistent for
about 6 months before somebody re-introduces a conflicting usage.

Yeah, that last is a really good point.

I do not, on the other hand, believe that there's no point in being
consistent about anything unless we're consistent about everything;
that's a straw man.

That wasn't my argument; rather, I was saying that if someone presents
a patch for s/bool/boolean/g and we accept it, then logically we should
also accept patches for any of these other cases as well. I doubt that
we would, if only because of the carpal-tunnel angle. Does that mean
our policy is "we'll be consistent as long as it doesn't add too many
characters"? Ugh.

regards, tom lane