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

Re: leakproof

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: leakproof
Date: 2012-02-21 16:54:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 EisentrautDate: 2012-02-21 17:05:57
Subject: Re: Potential reference miscounts and segfaults in plpython.c
Previous:From: Fujii MasaoDate: 2012-02-21 16:46:51
Subject: Re: [COMMITTERS] pgsql: Correctly initialise shared recoveryLastRecPtr in recovery.

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