>
>
> > I've updated word_similarity_op(text,text) to be leakproof, and
> > pg_proc agrees it is. I'm assuming word_similarity_op() is equivalent to
> > <%, though I haven't found explicit confirmation. However, using
> > word_similarity() instead of <% on a 100k row table, without any RLS
> > invo
Greetings,
Please don't top-post on these lists.
* Derek Hans (derek.h...@gmail.com) wrote:
> Thanks for the detailed response, super helpful in understanding what's
> happening, in particular understanding the risk of not marking functions as
> leakproof. I'll take a look at the underlying code
Thanks for the detailed response, super helpful in understanding what's
happening, in particular understanding the risk of not marking functions as
leakproof. I'll take a look at the underlying code to understand what's
involved in getting a function to be leakproof.
That said, it does seem like i
Greetings,
* Derek Hans (derek.h...@gmail.com) wrote:
> Unfortunately only "alter function" supports "leakproof" - "alter operator"
> does not. Is there a function-equivalent for marking operators as
> leakproof? Is there any documentation for which operators/functions are
> leakproof?
Tom's quer
Derek Hans writes:
> Unfortunately only "alter function" supports "leakproof" - "alter operator"
> does not. Is there a function-equivalent for marking operators as
> leakproof?
Leakproofness is a property of the underlying function, not the operator,
so that's where you change it.
> Is there an
Thanks for the pointer for marking functions as leakproof, I was unaware of
that whole concept.
Unfortunately only "alter function" supports "leakproof" - "alter operator"
does not. Is there a function-equivalent for marking operators as
leakproof? Is there any documentation for which operators/fu
Derek Hans writes:
>> However, wild-guess time: it might be that without access to the
>> table statistics, the "search like '%yo'" condition is estimated
>> to be too unselective to make an indexscan profitable. And putting
>> RLS in the way would disable that access if the ~~ operator is not
>>
>
>
> Your example is obscuring the issue by incorporating a tenant_name
> condition (where did that come from, anyway?) in one case and not
> the other. Without knowing how selective that is, it's hard to
> compare the EXPLAIN results.
>
>
That's RLS kicking in - RLS condition is defined as
((ten
>
>
> What are the RLS policies on the table?
>
> From select * from pg_policies:
"((tenant_name)::name = CURRENT_USER)"
> What is the definition of the GIN index?
>
> CREATE INDEX search__gist
ON public.search USING gist
(search COLLATE pg_catalog."default" gist_trgm_ops)
TABLESPACE
On 8/13/19 11:57 AM, Derek Hans wrote:
When using row level security, GIN and GIST indexes appear to get
ignored. Is this expected behavior? Can I change the query to get
PostgreSQL using the index? For example, with RLS enabled, this query:
What are the RLS policies on the table?
What is the
Derek Hans writes:
> When using row level security, GIN and GIST indexes appear to get ignored.
> Is this expected behavior? Can I change the query to get PostgreSQL using
> the index? For example, with RLS enabled, this query:
Your example is obscuring the issue by incorporating a tenant_name
co
11 matches
Mail list logo
