ansible-collections/community.postgresql

have a `comment` argument wherever an object is created

Ouverte

#354 ouverte le 12 oct. 2022

Voir sur GitHubGuide contributeur
 (3 commentaires) (3 réactions) (0 personne assignée)Python (116 forks)auto 404
help wanted

Métriques du dépôt

Stars
 (142 étoiles)
Métriques de merge PR
 (Merge moyen 13j 5h) (3 PRs mergées en 30 j)

Description

  From a user perspective I think it would be more convenient to have a `comment` argument wherever an object is created. To only change a comment, they need to be idempotent. At a quick glance, the argument would suit 11 modules:
  • postgresql_db: #646
  • postgresql_ext: #652
  • postgresql_idx
  • postgresql_lang (deprecated)
  • postgresql_publication: #654
  • postgresql_schema: #650
  • postgresql_sequence
  • postgresql_subscription: #655
  • postgresql_table
  • postgresql_tablespace: #651
  • postgresql_user: #649 (already had the feature, uses the shared function now)
  • add the comment argument value to check_input(...), check across all the modules
  • check reset functionality in all the modules except publication for consistency
  • add check_mode + mogrify to set_comment, fix tests across all the modules where it makes sense

I'd say the benefit of a comment argument or postgresql_comment module over postgresql_query is that we can validate the kind of object which is commented, to avoid SQL injections. As this is part of the query syntax, not a variable, we cannot rely on psycopg2/3 variable escaping.

Originally posted by @betanummeric in https://github.com/ansible-collections/community.postgresql/discussions/352#discussioncomment-3834647

Guide contributeur

Direction de recherche
Implémentez l'argument `comment` pour les modules restants (postgresql idx, postgresql sequence, postgresql table) en suivant le modèle des modules terminés comme postgresql schema. Assurez l'idempotence et utilisez les fonctions partagées `check input` et `set comment`.
Stack technique
pythonpostgresql
Domaine
backenddatabase
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
PythonPostgreSQLAnsible module development
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60