On Wed, Feb 22, 2012 at 10:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 > closely.)
Not exactly; I've kind of been playing it by ear, but I agree that out-of-memory errors based on the input value being huge are probably not something we want to stress out about too much. In theory you could probe for the approximate size of the value by using up nearly all the memory on the system, leaving a varying amount behind, and then see whether you get an out of memory error. But again, if people are going to that kind of trouble to ferret out just the approximate size of the data, it was probably a bad idea to let them log into the database at all, in any way, in the first place. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers