Dean Rasheed writes:
> Rather than (or perhaps as well as) marking all these leakproof,
> perhaps we should teach contain_leaky_functions() to automatically
> treat any no-arg function as leakproof, so that we allow user-defined
> functions too. Taking that one step further, perhaps what it should
On 26 September 2014 15:48, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane wrote:
>> > ISTM that the most appropriate solution here is to insist that all or none
>> > of the members of an operator class be marked leakproof. (Possi
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane wrote:
> > ISTM that the most appropriate solution here is to insist that all or none
> > of the members of an operator class be marked leakproof. (Possibly we
> > could restrict that to btree opclasses, but
On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane wrote:
> It strikes me that there's a significant gap in the whole "leakproof
> function" business, namely that no consideration has been given to
> planner-driven transformations of queries. As an example, if we
> have "a = b" and "b = c", the planner ma
It strikes me that there's a significant gap in the whole "leakproof
function" business, namely that no consideration has been given to
planner-driven transformations of queries. As an example, if we
have "a = b" and "b = c", the planner may generate and apply "a = c"
instead of one or both of tho
