On 31 January 2018 at 21:51, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed
> wrote:
>> On 30 January 2018 at 16:42, Tom Lane wrote:
>>> So I'm thinking that (a) we do not need to check for leaky functions used
>>> in window support, and (b) therefore there's no need to avoi
On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed wrote:
> On 30 January 2018 at 16:42, Tom Lane wrote:
>> So I'm thinking that (a) we do not need to check for leaky functions used
>> in window support, and (b) therefore there's no need to avoid leaky
>> behavior in in_range support functions. Objec
On 30 January 2018 at 16:42, Tom Lane wrote:
> So I'm thinking that (a) we do not need to check for leaky functions used
> in window support, and (b) therefore there's no need to avoid leaky
> behavior in in_range support functions. Objections?
>
Yes, I concur. Since window functions can only ap
I am wondering whether we need to worry about leakproofness in connection
with adding in_range support functions to btree opclasses. My initial
conclusion is not, but let me lay out the reasoning so people can check
it --- I might be missing something.
The first question is whether we need to enc
