ansible-collections/community.postgresql

have a `comment` argument wherever an object is created

Offen

#354 geöffnet am 12.10.2022

Auf GitHub ansehenContributor Guide
 (3 Kommentare) (3 Reaktionen) (0 zugewiesene Personen)Python (116 Forks)auto 404
help wanted

Repository-Metriken

Stars
 (142 Sterne)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

  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

Contributor Guide

Research-Richtung
Implementiere das Argument `comment` für die verbleibenden Module (postgresql idx, postgresql sequence, postgresql table) nach dem Muster der abgeschlossenen Module wie postgresql schema. Stelle die Idempotenz sicher und verwende die gemeinsamen Funktionen `check input` und `set comment`.
Tech Stack
pythonpostgresql
Domain
backenddatabase
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
Halber Tag
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
PythonPostgreSQLAnsible module development
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
60