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
Attachments:
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