Обсуждение: Why does contain_leaked_vars believe MinMaxExpr is safe?

Поиск
Список
Период
Сортировка

Why does contain_leaked_vars believe MinMaxExpr is safe?

От
Tom Lane
Дата:
MinMaxExpr is an implicit invocation of a btree comparison function.
Are we supposing that all of those are necessarily leakproof?
        regards, tom lane



Re: Why does contain_leaked_vars believe MinMaxExpr is safe?

От
Robert Haas
Дата:
On Tue, May 12, 2015 at 7:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> MinMaxExpr is an implicit invocation of a btree comparison function.
> Are we supposing that all of those are necessarily leakproof?

I suspect it's an oversight, because the comment gives no hint that
any such intention was present.  It's been more than three years since
I committed that code (under a different function name) so my memory
is a little fuzzy, but I believe it just didn't occur to me that
MinMaxExpr could include a function call.

I suspect it's safe in practice, but in theory it's probably a bug.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Why does contain_leaked_vars believe MinMaxExpr is safe?

От
Noah Misch
Дата:
On Wed, May 13, 2015 at 09:34:53AM -0400, Robert Haas wrote:
> On Tue, May 12, 2015 at 7:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > MinMaxExpr is an implicit invocation of a btree comparison function.
> > Are we supposing that all of those are necessarily leakproof?
> 
> I suspect it's an oversight, because the comment gives no hint that
> any such intention was present.  It's been more than three years since
> I committed that code (under a different function name) so my memory
> is a little fuzzy, but I believe it just didn't occur to me that
> MinMaxExpr could include a function call.
> 
> I suspect it's safe in practice, but in theory it's probably a bug.

Agreed; it is formally a bug.  We considered[1] special trust of operator
class members and decided against it.  Since almost every btree opfamily
member is leakproof in practice, I doubt the bug has harmed anyone.

[1] http://www.postgresql.org/message-id/flat/20110707223526.GJ1840@tornado.leadboat.com