Обсуждение: Now/current_date and proleakproof

Поиск
Список
Период
Сортировка

Now/current_date and proleakproof

От
Rod Taylor
Дата:
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

Re: Now/current_date and proleakproof

От
Tom Lane
Дата:
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

Re: Now/current_date and proleakproof

От
Rod Taylor
Дата:


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
Вложения

Re: Now/current_date and proleakproof

От
Tom Lane
Дата:
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