Replace over-optimistic Assert in partitioning code with a runtime test.

get_partition_parent felt that it could simply Assert that systable_getnext
found a tuple.  This is unlike any other caller of that function, and it's
unsafe IMO --- in fact, the reason I noticed it was that the Assert failed.
(OK, I was working with known-inconsistent catalog contents, but I wasn't
expecting the DB to fall over quite that violently.  The behavior in a
non-assert-enabled build wouldn't be very nice, either.)  Fix it to do what
other callers do, namely an actual runtime-test-and-elog.

Also, standardize the wording of elog messages that are complaining about
unexpected failure of systable_getnext.  90% of them say "could not find
tuple for <object>", so make the remainder do likewise.  Many of the
holdouts were using the phrasing "cache lookup failed", which is outright
misleading since no catcache search is involved.

1 files changed, 2 insertions, 2 deletions

diff --git a/contrib/sepgsql/proc.c b/contrib/sepgsql/proc.c
index 4ccf4a5e60d..73564edaa79 100644
--- a/contrib/sepgsql/proc.c
+++ b/contrib/sepgsql/proc.c
@@ -68,7 +68,7 @@ sepgsql_proc_post_create(Oid functionId)
 
 	tuple = systable_getnext(sscan);
 	if (!HeapTupleIsValid(tuple))
-		elog(ERROR, "catalog lookup failed for proc %u", functionId);
+		elog(ERROR, "could not find tuple for function %u", functionId);
 
 	proForm = (Form_pg_proc) GETSTRUCT(tuple);
 
@@ -261,7 +261,7 @@ sepgsql_proc_setattr(Oid functionId)
 							   SnapshotSelf, 1, &skey);
 	newtup = systable_getnext(sscan);
 	if (!HeapTupleIsValid(newtup))
-		elog(ERROR, "catalog lookup failed for function %u", functionId);
+		elog(ERROR, "could not find tuple for function %u", functionId);
 	newform = (Form_pg_proc) GETSTRUCT(newtup);
 
 	/*