Skip site navigation (1) Skip section navigation (2)

Re: leakproof

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Don Baccus <dhogaza(at)pacifier(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: leakproof
Date: 2012-02-22 15:21:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Anyway, to your point, I suppose I might hesitate to mark factorial
> leak-proof even if it didn't throw an error on overflow, because the
> time it takes to return an answer for larger inputs does grow rather
> rapidly.  But it's kind of a moot point because the error makes it not
> leak-proof anyway.  So maybe we're just splitting hairs here, however
> we decide to label this.

Speaking of hair-splitting ...

A strict interpretation of "no errors can be thrown" would, for example,
rule out any function that either takes or returns a varlena datatype,
since those are potentially going to throw out-of-memory errors if they
can't palloc a result value or a temporary detoasted input value.
I don't suppose that we want that, which means that this rule of thumb
is wrong in detail, and there had better be some more subtle definition
of what is okay or not, perhaps along the line of "must not throw any
errors that reveal anything useful about the input value".  Have we got
such a definition?  (I confess to not having followed this patch very

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-22 15:29:56
Subject: Re: VACUUM ANALYZE is faster than ANALYZE?
Previous:From: Greg SmithDate: 2012-02-22 14:43:40
Subject: Re: Patch: add timing of buffer I/O requests

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group