Qual é o problema de marcar uma função como LEAKPROOF no PostgreSQL quando a segurança em nível de linha está em vigor em uma configuração de locatário único?

Estou tentando entender as implicações de marcar uma função PostgreSQL como LEAKPROOF. Digamos que temos uma configuração de aplicativo da web (inquilino único), que é Navegador -> Servidor (Django, Rails, etc.) -> PostgreSQL. O servidor é o único que tem acesso ao PostgreSQL, o único que pode adicionar consultas de execução, executar funções, etc.

O servidor tenta consultar uma tabela no esquema público chamado foo. A tabela é apenas uma chave primária, ide um jsonbcampo,, barcom 100.000 linhas. O jsonbcampo possui um índice GIN. Quando a segurança em nível de linha não é aplicada, qualquer ->consulta barusa o índice GIN perfeitamente. No entanto, quando a segurança em nível de linha é aplicada, a segurança em nível de linha força uma varredura de sequência. Este é um "problema" conhecido, conforme abordado aqui , aqui , etc.

Depois de ler a documentação do PostgreSQL e vários posts, tenho dificuldade em ver o risco de substituir a jsonboperação de filtro por um equivalente LEAKPROOF. Eu sei que a documentação diz que poderia "vazar" informações, mas em uma configuração de locatário único, para quem isso estaria vazando? O servidor pode filtrar quaisquer mensagens de erro para o cliente e o próprio servidor é uma entidade confiável.