Thread: Now/current_date and proleakproof
Should now/current_date be marked leakproof?
I'm trying to push a `WHERE field >= current_date - interval '1 day'` type of clause into a security_barrier defined view.
--
Rod Taylor
Rod Taylor <rod.taylor@gmail.com> writes: > Should now/current_date be marked leakproof? Since it has no argument, that should be moot. regards, tom lane
On Sat, 17 Nov 2018 at 14:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rod Taylor <rod.taylor@gmail.com> writes:
> Should now/current_date be marked leakproof?
Since it has no argument, that should be moot.
Gah, you're right.
It seems to be because the below clause is timestamp without time zone:
WHERE current_date - interval '1 day'
This works as expected on 9.6 and head:
WHERE current_date::timestamp with time zone - interval '1 day' as ex2;
Of course, the first version without the cast does push through a barrier. So it's the timestamp_%_timestamptz operator functions that are missing the flag?
Attached is an example. It seems all 3 queries should be able to use the same type of plan.
Rod Taylor
Attachment
Rod Taylor <rod.taylor@gmail.com> writes: > So it's the timestamp_%_timestamptz operator functions that are missing the > flag? I think those are not marked leakproof because they aren't leakproof; they can throw errors for some inputs, or at least the required conversions invoke enough code that it's hard to be sure they can't. regards, tom lane