Table 9.20. Regular Expression Character-Entry Escapes
Escape Description
\a alert (bell) character, as in C
\b backspace, as in C
En revanche dans Perl \b correspond à une limite (boundary), cf https://perldoc.perl.org/perlrebackslas … 7D%2C-%5CB
Moralité vous essayez une expression régulière qui marcherait sûrement avec Perl mais non compatible avec Postgres.
La doc de Perl ci-dessus dit que \b est équivalent à
(?:(?<=\w)(?!\w)|(?<!\w)(?=\w))
donc vous pouvez essayer de remplacer par cette séquence.
]]>Il est quand vraiment dommage qu'il n'y ai pas la possibilité de réencoder les mots de passe en scram-sha...
]]>Il est aussi possible de créer des politiques de sécurité. Voir https://docs.postgresql.fr/14/ddl-rowsecurity.html pour les détails.
Merci beaucoup j'ai réussi !
]]>D'après la documentation https://www.postgresql.org/docs/current/auth-ldap.html
ldapserver
Names or IP addresses of LDAP servers to connect to. Multiple servers may be specified, separated by spaces.
Vous pouvez consulter le reste de la documentation pour voir ce que votre implementation ldap nécessite pour ldaps / ldaptls.
]]>Tout à fait possible. Cela dépend de la configuration du fichier pg_hba.conf.
]]>Voici la ligne GRANT correcte.
EXECUTE 'GRANT SELECT ON LARGE OBJECT ' || oid_data.id || ' TO ' || user_for_grant;
exemple pour restaurer a a la date de 08/06 a 22h00 avec un backupId = 20210608T210000 et un pg data =/data:
/usr/bin/barman recover --target-time "2021-06-05 22:00:00" --remote-ssh-command "ssh -o 'StrictHostKeyChecking=no' postgres@recover" target 20210608T210000 /data
Pour restaurer a la date la plus proche possible :
/usr/bin/barman recover --target-immediate --remote-ssh-command "ssh -o 'StrictHostKeyChecking=no' postgres@recover" target 20210608T210000 /data
Attention, barman doit pouvoir se connecter en ssh avec l'utilisateur postgres pour pouvoir fonctionner
les données dans /data de recover seront supprimées.
Une fois la restauration effectuée, il faudra demarre l'instance qui vient d'etre restaurée et pour pouvoir l'ouvrir en l'ecture/ecriture il faudra lancer la commande suivante :
select pg_wal_replay_resume();
Cordialement
Yohann
Bonjour,
Si quelqu'un a une idée, merci de bien vouloir m’aiguiller.
C'est un problème qui a l'air d'être lié à la version du driver JDBC utilisée.
Apparemment il faudrait le une version >=42.2.18. ( https://jdbc.postgresql.org/documentati … on_42.2.18 )
]]>bonjour,
essayez de faire les revoke correspondants avant la suppression du rôle.
Et ben, je n'ai pas eu le temps de répondre mais c'est une solution qui me convient!
Cela marche sans problème.
Merci ;-)
]]>