proleakproof vs opr_sanity test

In view of
http://www.postgresql.org/message-id/CAM2+6=U5YLZBre3V3WF9FFuL0gxR1egA3MiPh1Gu0JPsEUD7dg@mail.gmail.com
I went trawling for other places where the LEAKPROOF patch might have
overlooked something, by dint of grepping for prosecdef and seeing if
there was or should be parallel code for proleakproof.

I found one: opr_sanity.sql has a test to see if multiple pg_proc
references to the same underlying built-in function all have equivalent
properties, and that check is comparing prosecdef properties but not
proleakproof.  I tried adding proleakproof, and behold, I got this:

*** /home/postgres/pgsql/src/test/regress/expected/opr_sanity.out    Tue May 19 11:43:02 2015
--- /home/postgres/pgsql/src/test/regress/results/opr_sanity.out    Thu May 28 10:59:18 2015
***************
*** 130,142 ****     (p1.prolang != p2.prolang OR      p1.proisagg != p2.proisagg OR      p1.prosecdef != p2.prosecdef
OR     p1.proisstrict != p2.proisstrict OR      p1.proretset != p2.proretset OR      p1.provolatile != p2.provolatile
OR     p1.pronargs != p2.pronargs);
 
!  oid | proname | oid | proname 
! -----+---------+-----+---------
! (0 rows)  -- Look for uses of different type OIDs in the argument/result type fields -- for different aliases of the
samebuilt-in function.
 
--- 130,144 ----     (p1.prolang != p2.prolang OR      p1.proisagg != p2.proisagg OR      p1.prosecdef != p2.prosecdef
OR
+      p1.proleakproof != p2.proleakproof OR      p1.proisstrict != p2.proisstrict OR      p1.proretset != p2.proretset
OR     p1.provolatile != p2.provolatile OR      p1.pronargs != p2.pronargs);
 
!  oid | proname | oid  |  proname  
! -----+---------+------+-----------
!   68 | xideq   | 1319 | xideqint4
! (1 row)  -- Look for uses of different type OIDs in the argument/result type fields -- for different aliases of the
samebuilt-in function.
 

So I think we ought to fix xideqint4 to be marked leakproof and then
add this test.  That would only be in HEAD though since it'd require
an initdb.  Any objections?  Is there a reason to believe that a
built-in function might be leakproof when invoked from one function
OID but not another?
        regards, tom lane