Re: leakproof - Mailing list pgsql-hackers

From Robert Haas
Subject Re: leakproof
Date
Msg-id CA+TgmoaOKPdTj+VxhtCUykd8gkhy=fOnZ6q+jusjgZa4uzz=Gg@mail.gmail.com
Whole thread Raw
In response to leakproof  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: leakproof  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Feb 19, 2012 at 5:29 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> I missed all the fun while the "leakproof" addition to function attributes
> was being decided, so I know I'm late to the party. Today I had to go and
> look up what it actually meant. I have to say that I was a bit surprised. I
> expected it to refer to memory management in some way. I don't honestly
> think "leakproof" as a term is going to convey much to lots of people. Can
> we come up with a more descriptive term?

We bikeshed on that topic a while back and nobody suggested anything
that got more than 1 or 2 votes.  But I'm still happy to rename it if
we can come up with something better, because I'm not in love with it
either.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: pl/python long-lived allocations in datum->dict transformation
Next
From: Robert Haas
Date:
Subject: Re: Reducing bgwriter wakeups