On Sun, Feb 19, 2012 at 6:20 PM, Don Baccus <dhogaza(at)pacifier(dot)com> wrote:
>
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>
>> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

• Re: leakproof at 2012-02-20 02:20:09 from Don Baccus

Responses

• Re: leakproof at 2012-02-22 12:57:50 from Robert Haas

pgsql-hackers by date

Next:	From: Peter Eisentraut	Date: 2012-02-21 17:05:57
	Subject: Re: Potential reference miscounts and segfaults in plpython.c
Previous:	From: Fujii Masao	Date: 2012-02-21 16:46:51
	Subject: Re: [COMMITTERS] pgsql: Correctly initialise shared recoveryLastRecPtr in recovery.