On Mon, Feb 27, 2012 at 1:50 PM, David E. Wheeler wrote:
> On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>
>>> I also liked Kevin's suggestion of DISCREET
>>
>> That would probably create too much confusion with "discrete".
>
> SECRETE?
BOUND? GAGGED?
--
When confronted by a difficult pr
2012/2/27 David E. Wheeler :
> On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>
>>> I also liked Kevin's suggestion of DISCREET
>>
>> That would probably create too much confusion with "discrete".
>
> SECRETE?
next one
MUTE ?
Regards
Pavel
>
> David
>
>
> --
> Sent via pgsql-hackers mail
On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>> I also liked Kevin's suggestion of DISCREET
>
> That would probably create too much confusion with "discrete".
SECRETE?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On 02/26/2012 08:23 PM, Tom Lane wrote:
Robert Haas writes:
On Sun, Feb 26, 2012 at 6:44 PM, A.M. 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 lo
Robert Haas writes:
> On Sun, Feb 26, 2012 at 6:44 PM, A.M. 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 s
On Sun, Feb 26, 2012 at 6:44 PM, A.M. wrote:
> If you are willing to go full length, then the computer science term is
> "referential transparency", no?
>
> http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
>
> So a function could be described as "REFERENTIALLY TRANSPARENT"
On Feb 26, 2012, at 10:39 AM, Peter Eisentraut wrote:
> On ons, 2012-02-22 at 10:56 -0500, Andrew Dunstan wrote:
>> The trouble with "leakproof" is that it
>> doesn't point to what it is that's not leaking, which is information
>> rather than memory, as many might imagine (and I did) without fu
On ons, 2012-02-22 at 10:56 -0500, Andrew Dunstan wrote:
> The trouble with "leakproof" is that it
> doesn't point to what it is that's not leaking, which is information
> rather than memory, as many might imagine (and I did) without further
> hints. I'm not sure any single English word would be
On fre, 2012-02-24 at 23:00 -0500, Noah Misch wrote:
> I also liked Kevin's suggestion of DISCREET
That would probably create too much confusion with "discrete".
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Wed, Feb 22, 2012 at 06:30:37PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 02/22/2012 04:29 PM, Marc Munro wrote:
> >> As the developer of veil I feel marginally qualified to bikeshed here:
> >> how about "silent"? A silent function being one that will not blab.
>
> > I also made
* Andrew Dunstan wrote:
Returning to the original point, I've come to the conclusion that
"pure" isn't the right way to go. The trouble with "leakproof" is that
it doesn't point to what it is that's not leaking, which is
information rather than memory, as many might imagine (and I did)
without f
On Wed, Feb 22, 2012 at 6:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/22/2012 04:29 PM, Marc Munro wrote:
>>> As the developer of veil I feel marginally qualified to bikeshed here:
>>> how about "silent"? A silent function being one that will not blab.
>
>> I also made this suggesti
Andrew Dunstan writes:
> On 02/22/2012 04:29 PM, Marc Munro wrote:
>> As the developer of veil I feel marginally qualified to bikeshed here:
>> how about "silent"? A silent function being one that will not blab.
> I also made this suggestion later in the day.
SILENT isn't a bad idea. It seems
On Wed, Feb 22, 2012 at 10:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> Anyway, to your point, I suppose I might hesitate to mark factorial
>> leak-proof even if it didn't throw an error on overflow, because the
>> time it takes to return an answer for larger inputs does grow rather
>> rapidly
On 02/22/2012 04:29 PM, Marc Munro wrote:
On Wed, 2012-02-22 at 12:44 -0400, Andrew Dunstan wrote:
Returning to the original point, I've come to the conclusion that
"pure"
isn't the right way to go. The trouble with "leakproof" is that it
doesn't point to what it is that's not leaking, which
On Wed, 2012-02-22 at 12:44 -0400, Andrew Dunstan wrote:
> Returning to the original point, I've come to the conclusion that
> "pure"
> isn't the right way to go. The trouble with "leakproof" is that it
> doesn't point to what it is that's not leaking, which is information
> rather than memory,
On 02/22/2012 11:14 AM, Kevin Grittner wrote:
Andrew Dunstan wrote:
Returning to the original point, I've come to the conclusion that
"pure" isn't the right way to go. The trouble with "leakproof" is
that it doesn't point to what it is that's not leaking, which is
information rather than mem
Andrew Dunstan wrote:
> Returning to the original point, I've come to the conclusion that
> "pure" isn't the right way to go. The trouble with "leakproof" is
> that it doesn't point to what it is that's not leaking, which is
> information rather than memory, as many might imagine (and I did)
> w
On 02/22/2012 10:21 AM, Tom Lane wrote:
Robert Haas writes:
Anyway, to your point, I suppose I might hesitate to mark factorial
leak-proof even if it didn't throw an error on overflow, because the
time it takes to return an answer for larger inputs does grow rather
rapidly. But it's kind of
Robert Haas writes:
> Anyway, to your point, I suppose I might hesitate to mark factorial
> leak-proof even if it didn't throw an error on overflow, because the
> time it takes to return an answer for larger inputs does grow rather
> rapidly. But it's kind of a moot point because the error makes
On Tue, Feb 21, 2012 at 11:54 AM, Jeff Janes wrote:
> 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 woul
On Sun, Feb 19, 2012 at 6:20 PM, Don Baccus wrote:
>
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>
>> Robert Haas 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"
On Sun, Feb 19, 2012 at 8:20 PM, Don Baccus wrote:
>
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>
>> Robert Haas 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"
Peter Eisentraut writes:
> On mån, 2012-02-20 at 01:17 -0500, Robert Haas wrote:
>> For the present application (pushdown into security views), we really
>> only care whether the function has side effects, such as throwing an
>> error or mutating global state.
> How about [NO] SIDEEFFECTS?
Well
On mån, 2012-02-20 at 01:17 -0500, Robert Haas wrote:
> For the present application (pushdown into security views), we really
> only care whether the function has side effects, such as throwing an
> error or mutating global state.
How about [NO] SIDEEFFECTS?
--
Sent via pgsql-hackers mailing li
Greg Stark wrote:
> I suspect this is wrong for similar reasons as "pure" but I'll throw
> it out there: "hermetic"
I personally have no problem with "leakproof", but if it does not tickle
the right associations with many people:
What about "secure"? It is also not self-explanatory, but it might
On 2012-02-20 06:37, Don Baccus wrote:
On Feb 19, 2012, at 7:24 PM, Tom Lane wrote:
It's not clear to me whether pure/leakproof functions are meant to be a
strict subset of immutable functions
Superset, not subset, unless my guessing is wrong. How could "pure" be a subset of
"immutable"?
If
On Sun, Feb 19, 2012 at 10:24 PM, Tom Lane wrote:
> Don Baccus writes:
>> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>>> Hmm, "pure" doesn't sound bad to me. Nice and short.
>
>> Technically, "pure" is stronger than "has no side effects":
>> http://en.wikipedia.org/wiki/Pure_function
>> Result
On Feb 19, 2012, at 7:24 PM, Tom Lane wrote:
> Don Baccus writes:
>> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>>> Hmm, "pure" doesn't sound bad to me. Nice and short.
>
>> Technically, "pure" is stronger than "has no side effects":
>> http://en.wikipedia.org/wiki/Pure_function
>> Result ca
Don Baccus writes:
> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>> Hmm, "pure" doesn't sound bad to me. Nice and short.
> Technically, "pure" is stronger than "has no side effects":
> http://en.wikipedia.org/wiki/Pure_function
> Result can't depend on state (for instance, database contents), e
I suspect this is wrong for similar reasons as "pure" but I'll throw
it out there: "hermetic"
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
> Robert Haas 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 thro
Robert Haas writes:
> On Sun, Feb 19, 2012 at 5:29 PM, Andrew Dunstan wrote:
>> 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 someth
On Sun, Feb 19, 2012 at 5:29 PM, Andrew Dunstan 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 i
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 honestl
35 matches
Mail list logo
