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":
> 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.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2012-02-21 17:05:57|
|Subject: Re: Potential reference miscounts and segfaults in
|Previous:||From: Fujii Masao||Date: 2012-02-21 16:46:51|
|Subject: Re: [COMMITTERS] pgsql: Correctly initialise shared
recoveryLastRecPtr in recovery.|