Make opr_sanity test complain about built-in functions marked prosecdef.

Currently, there are no built-in functions that are SECURITY DEFINER.
But we just found an instance where one was mistakenly marked that way,
so it seems prudent to add a test about it.  If we ever grow some
functions that are intentionally SECURITY DEFINER, we can alter the
expected output of this test, or adjust the query to filter out functions
for which it's okay.

Per suggestion from Robert Haas.

Discussion: https://postgr.es/m/CA+TgmoYXg7McY33+jbWmG=rS-HNUur0S6W8Q8kVNFf7epFimVA@mail.gmail.com

Author: tglsfdc

src/test/regress/expected/opr_sanity.out

@@ -96,6 +96,16 @@ WHERE proiswindow AND (proisagg OR proretset);
 -----+---------
 (0 rows)
 
+-- currently, no built-in functions should be SECURITY DEFINER;
+-- this might change in future, but there will probably never be many.
+SELECT p1.oid, p1.proname
+FROM pg_proc AS p1
+WHERE prosecdef
+ORDER BY 1;
+ oid | proname 
+-----+---------
+(0 rows)
+
 -- pronargdefaults should be 0 iff proargdefaults is null
 SELECT p1.oid, p1.proname
 FROM pg_proc AS p1

src/test/regress/sql/opr_sanity.sql

@@ -95,6 +95,13 @@ SELECT p1.oid, p1.proname
 FROM pg_proc AS p1
 WHERE proiswindow AND (proisagg OR proretset);
 
+-- currently, no built-in functions should be SECURITY DEFINER;
+-- this might change in future, but there will probably never be many.
+SELECT p1.oid, p1.proname
+FROM pg_proc AS p1
+WHERE prosecdef
+ORDER BY 1;
+
 -- pronargdefaults should be 0 iff proargdefaults is null
 SELECT p1.oid, p1.proname
 FROM pg_proc AS p1