From: Jonathan S. Katz <jkatz@postgresql.org>
To: Magnus Hagander <magnus@hagander.net>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: language cleanups in code and docs
Date: Wed, 17 Jun 2020 09:32:55 -0400
Message-ID: <172c908a-17f4-59e0-446f-a6f2e1217e14@postgresql.org> (raw)
In-Reply-To: <CABUevEy0vPwsuQ8K_=xLW6=4hFoVCvdxtDpr14FXW55i=8CZYw@mail.gmail.com>
References: <20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de>
<CABUevEy0vPwsuQ8K_=xLW6=4hFoVCvdxtDpr14FXW55i=8CZYw@mail.gmail.com>
On 6/17/20 6:32 AM, Magnus Hagander wrote:
> In looking at this I realize we also have exactly one thing referred to
> as "blacklist" in our codebase, which is the "enum blacklist" (and then
> a small internal variable in pgindent). AFAICT, it's not actually
> exposed to userspace anywhere, so we could probably make the attached
> change to blocklist at no "cost" (the only thing changed is the name of
> the hash table, and we definitely change things like that in normal
> releases with no specific thought on backwards compat).
+1. Though if we are doing that, we should also handle "whitelist" too,
as this attached patch does. It's mostly in comments (with one Perl
variable), but I switched the language around to use "allowed"
Jonathan
Attachments:allowed.patch (text/plain, 5.3K) downloaddiff --git a/contrib/postgres_fdw/postgres_fdw.h b/contrib/postgres_fdw/postgres_fdw.hindex eef410db39..3364a203c7 100644--- a/contrib/postgres_fdw/postgres_fdw.h+++ b/contrib/postgres_fdw/postgres_fdw.h@@ -77,7 +77,7 @@ typedef struct PgFdwRelationInfo
bool use_remote_estimate;
Cost fdw_startup_cost;
Cost fdw_tuple_cost;
- List *shippable_extensions; /* OIDs of whitelisted extensions */+ List *shippable_extensions; /* OIDs of allowed extensions */
/* Cached catalog information. */
ForeignTable *table;
diff --git a/contrib/postgres_fdw/shippable.c b/contrib/postgres_fdw/shippable.cindex 3433c19712..8a3dca9e90 100644--- a/contrib/postgres_fdw/shippable.c+++ b/contrib/postgres_fdw/shippable.c@@ -111,7 +111,8 @@ InitializeShippableCache(void)
*
* Right now "shippability" is exclusively a function of whether the object
* belongs to an extension declared by the user. In the future we could
- * additionally have a whitelist of functions/operators declared one at a time.+ * additionally have a list of allowed functions/operators declared one at a+ * time.
*/
static bool
lookup_shippable(Oid objectId, Oid classId, PgFdwRelationInfo *fpinfo)
diff --git a/src/backend/access/hash/hashvalidate.c b/src/backend/access/hash/hashvalidate.cindex 6f14a9fb45..744d22b042 100644--- a/src/backend/access/hash/hashvalidate.c+++ b/src/backend/access/hash/hashvalidate.c@@ -309,7 +309,7 @@ check_hash_func_signature(Oid funcid, int16 amprocnum, Oid argtype)
* that are different from but physically compatible with the opclass
* datatype. In some of these cases, even a "binary coercible" check
* fails because there's no relevant cast. For the moment, fix it by
- * having a whitelist of allowed cases. Test the specific function+ * having a list of allowed cases. Test the specific function
* identity, not just its input type, because hashvarlena() takes
* INTERNAL and allowing any such function seems too scary.
*/
diff --git a/src/backend/utils/adt/lockfuncs.c b/src/backend/utils/adt/lockfuncs.cindex e992d1bbfc..267fc7adfd 100644--- a/src/backend/utils/adt/lockfuncs.c+++ b/src/backend/utils/adt/lockfuncs.c@@ -632,9 +632,9 @@ pg_isolation_test_session_is_blocked(PG_FUNCTION_ARGS)
/*
* Check if blocked_pid is waiting for a safe snapshot. We could in
* theory check the resulting array of blocker PIDs against the
- * interesting PIDs whitelist, but since there is no danger of autovacuum- * blocking GetSafeSnapshot there seems to be no point in expending cycles- * on allocating a buffer and searching for overlap; so it's presently+ * interesting list of allowed PIDs, but since there is no danger of+ * autovacuum blocking GetSafeSnapshot there seems to be no point in expending+ * cycles on allocating a buffer and searching for overlap; so it's presently
* sufficient for the isolation tester's purposes to use a single element
* buffer and check if the number of safe snapshot blockers is non-zero.
*/
diff --git a/src/tools/pginclude/README b/src/tools/pginclude/READMEindex a067c7f472..d1906a3516 100644--- a/src/tools/pginclude/README+++ b/src/tools/pginclude/README@@ -64,7 +64,7 @@ with no prerequisite headers other than postgres.h (or postgres_fe.h
or c.h, as appropriate).
A small number of header files are exempted from this requirement,
-and are whitelisted in the headerscheck script.+and are allowed in the headerscheck script.
The easy way to run the script is to say "make -s headerscheck" in
the top-level build directory after completing a build. You should
@@ -86,7 +86,7 @@ the project's coding language is C, some people write extensions in C++,
so it's helpful for include files to be C++-clean.
A small number of header files are exempted from this requirement,
-and are whitelisted in the cpluspluscheck script.+and are allowed in the cpluspluscheck script.
The easy way to run the script is to say "make -s cpluspluscheck" in
the top-level build directory after completing a build. You should
diff --git a/src/tools/pgindent/pgindent b/src/tools/pgindent/pgindentindex 457e328824..06e4d68991 100755--- a/src/tools/pgindent/pgindent+++ b/src/tools/pgindent/pgindent@@ -54,10 +54,10 @@ $excludes ||= "$code_base/src/tools/pgindent/exclude_file_patterns"
# some names we want to treat like typedefs, e.g. "bool" (which is a macro
# according to <stdbool.h>), and may include some names we don't want
# treated as typedefs, although various headers that some builds include
-# might make them so. For the moment we just hardwire a whitelist of names-# to add and a blacklist of names to remove; eventually this may need to be-# easier to configure. Note that the typedefs need trailing newlines.-my @whitelist = ("bool\n");+# might make them so. For the moment we just hardwire a list of allowed of+# names to add and a blacklist of names to remove; eventually this may need to+# be easier to configure. Note that the typedefs need trailing newlines.+my @allowed = ("bool\n");
my %blacklist = map { +"$_\n" => 1 } qw(
ANY FD_SET U abs allocfunc boolean date digit ilist interval iterator other
@@ -134,8 +134,8 @@ sub load_typedefs
}
}
- # add whitelisted entries- push(@typedefs, @whitelist);+ # add allowed entries+ push(@typedefs, @allowed);
# remove blacklisted entries
@typedefs = grep { !$blacklist{$_} } @typedefs;
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jkatz@postgresql.org, magnus@hagander.net, andres@anarazel.de
Subject: Re: language cleanups in code and docs
In-Reply-To: <172c908a-17f4-59e0-446f-a6f2e1217e14@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox