In view of
http://www.postgresql.org/message-id/CAM2+6=u5ylzbre3v3wf9fful0gxr1ega3miph1gu0jpseud...@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 same built-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 same built-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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
