Re: leakproof - Mailing list pgsql-hackers

From Tom Lane
Subject Re: leakproof
Date
Msg-id 19641.1330305796@sss.pgh.pa.us
Whole thread Raw
In response to Re: leakproof  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: leakproof  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Feb 26, 2012 at 6:44 PM, A.M. <agentm@themactionfaction.com> wrote:
>> http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
>> So a function could be described as "REFERENTIALLY TRANSPARENT".

> Hmm, I think that's very close to what we're looking for.  It might be
> slightly stronger, in that it could conceivably be OK for a leakproof
> function to read, but not modify, global variables... but I can't
> think of any particular reason why we'd want to allow that case.
> OTOH, it seems to imply that referential transparency is a property of
> expressions built from pure functions, and since what we're labeling
> here are functions, that brings us right back to PURE.

Yeah.  Comparing that page to the one on pure functions, there doesn't
seem to be any difference that is relevant to what we're concerned
about.  And neither page directly addresses the question of error
conditions, though if you hold your head at the proper angle you might
argue that that's implicit in the "no side effect" rule.  But I think
we're going to have to clearly document that requirement no matter
what term we choose.

> I'm thinking we should go with PURE.

Works for me.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: leakproof
Next
From: Andrew Dunstan
Date:
Subject: Re: leakproof