PG-1491 Simplify cache lookup logic to make it easier to reason about

This caused our code to act in a flaky way when looking up the SMGR
key for relations without storage, e.g. with InvalidRelFileNumber.

contrib/pg_tde/README.md

@@ -162,4 +162,6 @@ The extension provides the following helper functions:
 
 ### pg_tde_is_encrypted(tablename)
 
-Returns `t` if the relation is encrypted, or `f` otherwise.
+Returns `t` if the relation is encrypted, if unencrypted `f` or `NULL` if the
+relation lacks storage, i.e. views, foreign tables, and partitioning tables and
+indexes.

contrib/pg_tde/documentation/docs/functions.md

@@ -264,7 +264,9 @@ The `ensure_new_key` parameter instructs the function how to handle a principal
 
 ### pg_tde_is_encrypted
 
-Tells if a relation is encrypted using the `pg_tde` extension or not.
+Tells if a relation is encrypted using the `pg_tde` extension or not. Returns
+`NULL` if a relation lacks storage like views, foreign tables, and partitioned
+tables and indexes.
 
 To verify that a table is encrypted, run the following statement:
 

contrib/pg_tde/src/access/pg_tde_tdemap.c

@@ -1210,9 +1210,7 @@ pg_tde_get_key_from_cache(const RelFileLocator *rlocator, uint32 key_type)
 	{
 		RelKeyCacheRec *rec = tde_rel_key_cache.data + i;
 
-		if ((rlocator->relNumber == InvalidRelFileNumber ||
-			 RelFileLocatorEquals(rec->locator, *rlocator)) &&
-			rec->key.rel_type & key_type)
+		if (RelFileLocatorEquals(rec->locator, *rlocator) && rec->key.rel_type & key_type)
 		{
 			return &rec->key;
 		}