GammaGames's questions

Existe alguma desvantagem em colocar tabelas de junção em seu próprio esquema?

Título, eu poderia ter alguns esquemas:

• aplicativo
  • do utilizador
  • permissão
• app_join
  • permissão_do_usuário

Se eu estiver trabalhando com sql, terei que incluir os nomes completos dos esquemas, o que não faz muita diferença, e se eu usar um orm, posso chamar suas funções de relacionamento e ignorar completamente o conhecimento dos esquemas. Existe alguma desvantagem óbvia com esta configuração? Qualquer coisa que só se revelasse em grande escala?

Eu tenho um backup do PostgreSQL 15 que estou tentando importar para o PostgreSQL 16. Uma das principais alterações entre as versões é "Restringir os privilégios do CREATEROLE e sua capacidade de modificar outras funções"

Anteriormente, as funções com privilégios CREATEROLE podiam alterar muitos aspectos de qualquer função que não fosse de superusuário. Essas alterações, incluindo a adição de membros, agora exigem que a função que solicita a alteração tenha permissão ADMIN OPTION.

Isso significa que dumps anteriores do banco de dados apresentam erros de lançamento de comandos de concessão de função. O sql foi obtido com pg_dumpall --roles-only( --no-ownernão tem efeito):

GRANT role TO user1 GRANTED BY user0;

ERROR:  permission denied to grant privileges as role "user0"
DETAIL:  The grantor must have the ADMIN option on role "role".

Tentei conceder as funções com admin para não ter esse problema quando tentarmos conceder no futuro, mas isso coloca os comandos fora de ordem e ainda falham na restauração:

GRANT role TO user1 GRANTED BY user0;
GRANT role TO user2 GRANTED BY user0;
GRANT role TO user3 GRANTED BY user0;
GRANT role TO user0 WITH ADMIN OPTION GRANTED BY [me];

Existe alguma maneira de deixar de lado os GRANTED BYcomandos ou qualquer outra maneira de corrigir isso além de vasculhar as permissões no PostgreSQL 15 para que sejam importadas sem problemas?

Editar: user0 já é um superusuário

Tenho um banco de dados postgresql configurado com pgbackrest para backups. Ele retém backups completos por 7 dias:

[global]
repo1-retention-full-type=time
repo1-retention-full=7

Configurei o cron para criar um backup completo no domingo com backups incrementais todos os dias. Isso funciona conforme o esperado e remove backups completos depois que o mais recente tiver mais de 7 dias. O crontab real chama um script que usa os comandos pgbackrest, mas para simplificar:

0 0 * * 0   root    pgbackrest --type=full backup
0 0 * * 1-6 root    pgbackrest backup

Estou procurando configurar o pgbackrest para criar backups completos automaticamente a cada 7 dias, então precisaria apenas de um cron job:

0 0 * * *   root    pgbackrest backup

Isso é possível ou terei que escrever alguma lógica bash no meu script?

Estou trabalhando na configuração da autenticação LDAP para um banco de dados PostgreSQL e adicionei o seguinte no meu pg_hba.confarquivo:

# TYPE  DATABASE    USER    ADDRESS     METHOD
host    all         all     all         ldap ldapurl="ldap://example.local/dc=example,dc=local?sAMAccountName" ldapbinddn="username" ldapbindpasswd="password"

Funciona! Mas agora eu gostaria de armazenar o nome de usuário e a senha como variáveis ​​de ambiente, como faço para a maioria das minhas configurações. Tentei adicionar o nome de usuário e a senha como $LDAPUSERNAME ou "$LDAPUSERNAME", mas eles não estão inserindo nenhum valor. Isso é possível?

Observação: o banco de dados será executado em um contêiner docker. Se eu tiver que executar algum script para processar o pg_hba.confarquivo antes de iniciar o banco de dados, eu posso.