On 26 September 2014 15:48, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that the most appropriate solution here is to insist that all or none
of the members of an operator class
Dean Rasheed dean.a.rash...@gmail.com 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,
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us 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
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 those
