From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oliver Ford <ojford(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: WINDOW RANGE patch versus leakproofness |
Date: | 2018-01-31 10:52:28 |
Message-ID: | CAEZATCXkYtMQjWsTr-cc6j9YCTwFLakeKOGSnqPi5bsGi_Yh9A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 January 2018 at 16:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 appear in the SELECT
target list and ORDER BY clauses, they should never appear in a qual
that gets considered for push down, and thus contain_leaked_vars()
should never see a window function.
Moreover, contain_leaked_vars() is intentionally coded defensively, so
if it ever does somehow see a window function (or any other unexpected
node type) it will return true and the resulting qual/restrictinfo
will be marked leaky, and not pushed through security barriers.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2018-01-31 11:34:46 | BUG #15039: some question about hash index code |
Previous Message | Gaddam Sai Ram | 2018-01-31 10:51:01 | Re: Help needed in using 'on_dsm_detach' callback |