On Sun, Feb 19, 2012 at 6:20 PM, Don Baccus <dhog...@pacifier.com> wrote: > > On Feb 19, 2012, at 5:42 PM, Tom Lane wrote: > >> Robert Haas <robertmh...@gmail.com> writes: >>> Having now spent far too much time in bed with that patch, I'm feeling >>> like the concept that we are really looking for there is what some >>> languages call "pure" - that is, there must be no side effects, >>> whether by throwing exceptions or otherwise. >> >> Hmm, "pure" doesn't sound bad to me. Nice and short. >> > > Technically, "pure" is stronger than "has no side effects": > > http://en.wikipedia.org/wiki/Pure_function > > Result can't depend on state (for instance, database contents), either. This > is the typical definition used in functional programming. > > gcc extends this to allow use of global variables in a "pure" function (the > stricter definition is met by "const" functions). PG has "immutable", so a > slightly weaker "pure" probably wouldn't be terribly confusing given the gcc > precedent (probably across their family of compilers). > > "D" adopts the stricter definition of "pure". > > So there's some confusion around the term. > > But … > > I picked up this thread after "leakproof" was settled on and was curious as > to what "leakproof" was supposed to be as I didn't read the earlier posts. I > assumed it meant "doesn't leak memory", which seems admirable and typical and > not needful of an attribute on the function declaration. > > "pure" is definitely less confusing IMO, if it's congruent with the weaker > sense of "pure" that's found in some languages/implementations.
I don't think that "pure" is sufficient to be leakproof. For example, if I have a function which is pure but which takes an unusually long time to evaluate for some unique pathological combination of arguments, I don't think that it would be considered leakproof. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
