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

Re: leakproof

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: leakproof
Date: 2012-02-27 02:15:55
Message-ID: 4F4AE75B.3020100@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 02/26/2012 08:23 PM, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>> On Sun, Feb 26, 2012 at 6:44 PM, A.M.<agentm(at)themactionfaction(dot)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.
>
> 			

Not for me. My objection is the same as when I started this thread - 
that the term doesn't convey to someone just looking at it the salient 
point about the feature, any more then LEAKPROOF does. SILENT strikes me 
as much closer to what is actually described.

cheers

andrew

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-27 02:47:50
Subject: Re: foreign key locks, 2nd attempt
Previous:From: Tom LaneDate: 2012-02-27 01:23:16
Subject: Re: leakproof

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