Zum Hauptinhalt springen
connic

PostgreSQL

Von connic
Inbound

Starte einen Agenten mit einem NOTIFY aus deiner Datenbank. Ein Trigger oder deine Anwendung sendet die Zeile, und connic hält die Datenbankverbindung offen.

Publisher
Von connic
Modi
Inbound
Einrichtung
Dashboard oder connectors/*.yaml
Dokumentation
PostgreSQL Docs

Sende die Zeile aus einem Trigger

Ruf pg_notify() aus einer Trigger-Funktion oder aus deiner Anwendung auf. Jede Notification auf dem Channel startet alle verknüpften Agenten.

Trigger oder Anwendungscode
Ein Trigger erfasst jeden Insert und jedes Update einer Tabelle, egal welcher Dienst geschrieben hat. NOTIFY aus deiner Anwendung funktioniert genauso.
Kleine Payloads
PostgreSQL begrenzt eine Notification auf 8000 Bytes. Sende IDs und wichtige Felder und lass den Agenten den vollständigen Datensatz laden.
Ein Channel pro Event-Typ
Getrennte Channels wie orders_created und users_updated halten jeden Agenten bei den Events, die er bearbeitet. Namen bestehen aus Buchstaben, Ziffern und Unterstrichen.
notify_new_order.sql
CREATE OR REPLACE FUNCTION notify_new_order()
RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify(
    'orders_created',
    json_build_object(
      'order_id', NEW.id,
      'customer_id', NEW.customer_id,
      'total_cents', NEW.total_cents
    )::text
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_created
  AFTER INSERT ON orders
  FOR EACH ROW
  EXECUTE FUNCTION notify_new_order();

Erhalte die Payload als Objekt

Mit Parse JSON Payload, standardmäßig aktiv, erreicht eine JSON-Notification den Agenten als Objekt, ergänzt um einen _postgres-Block.

JSON-Objekte
Die Keys der Notification werden zu Feldern der obersten Ebene, und _postgres ergänzt Channel, Backend-Prozess-ID und Zeitpunkt.
Alles andere
Reiner Text kommt unter message an, andere JSON-Werte wie Arrays unter data.
Parse JSON Payload aus
Jede Notification kommt als unveränderter String unter message an.
payload.json
{
  "order_id": "ord_8812",
  "customer_id": "cus_4102",
  "total_cents": 489000,
  "_postgres": {
    "channel": "orders_created",
    "pid": 48213,
    "timestamp": "2026-10-13T09:00:00.123456"
  }
}
plain-text-payload.json
{
  "message": "nightly import finished",
  "_postgres": {
    "channel": "imports",
    "pid": 48213,
    "timestamp": "2026-10-13T02:00:00.481022"
  }
}

Halte den Listener in deinem Code

Deklariere ihn in connectors/. Host, Datenbank und Login liegen in einer Connection, und eine im Code deklarierte Verbindung lauscht, sobald das Deployment live geht.

connectors/new-orders.yaml
type: postgres
name: New orders
connection: shop-postgres
bridge: office-network
config:
  channel: orders_created
agents:
  - order-reviewer
create: connectors/new-orders.yaml (postgres)

Eine Datenbankverbindung, kein Polling

Jede Verbindung hält genau eine Datenbankverbindung offen und wartet, bis PostgreSQL Notifications schickt. Deine Tabellen fragt sie nie ab.

Ein Nutzer mit wenigen Rechten
Der Datenbanknutzer braucht CONNECT für die Datenbank. Für Notifications sind keine Tabellenrechte nötig.
Lücken werden nicht nachgeholt
PostgreSQL hebt Notifications für einen Listener ohne aktive Datenbankverbindung nicht auf. Was gesendet wird, während die Verbindung pausiert ist oder sich neu verbindet, geht verloren.
Private Datenbanken
Leite die Datenbankverbindung über eine connic Bridge in deinem Netzwerk. Die Bridge baut nur ausgehende Verbindungen auf, du öffnest also keine eingehende Firewall-Regel.
  1. Verbinden

    connic meldet sich mit deinen Zugangsdaten an, nutzt den gewählten SSL-Modus und führt LISTEN auf dem Channel aus.

  2. Lauschen

    Jedes NOTIFY auf dem Channel startet einen Run für jeden verknüpften Agenten.

  3. Prüfen

    Alle 30 Sekunden prüft connic, ob die Datenbankverbindung noch steht.

  4. Neu verbinden

    Bricht die Datenbankverbindung ab, versucht connic es mit wachsendem Abstand von bis zu zwei Minuten erneut. Ein falsches Passwort oder eine fehlende Datenbank stoppt den Listener mit einem Fehler in den Logs der Verbindung.

Wo ein Postgres-Trigger passt

Wähle ein Szenario und sieh, welche Änderung die Notification sendet, was der Agent bekommt und wohin das Ergebnis geht.

Ein Trigger auf customers sendet jede Anmeldung, und ein ausgehender Webhook schreibt das Firmenprofil in dein CRM.

Neue Anmeldung
Postgres Inbound
customer-enricher
Profil im CRM
payload.json
{
  "customer_id": "cus_4102",
  "email": "jana@example.com",
  "company": "Example GmbH",
  "_postgres": {
    "channel": "new_customers",
    "pid": 48213,
    "timestamp": "2026-10-13T09:00:00.123456"
  }
}
outbound-payload.json
{
  "run_id": "550e8400-e29b-41d4-a716-446655440000",
  "agent_name": "customer-enricher",
  "status": "completed",
  "output": "Example GmbH: logistics software, 40 people, Berlin.",
  "error": null,
  "started_at": "2026-10-13T09:00:00Z",
  "ended_at": "2026-10-13T09:00:05Z",
  "token_usage": {
    "input_tokens": 640,
    "output_tokens": 48,
    "thinking_tokens": 0,
    "cached_input_tokens": 0,
    "total_tokens": 688
  }
}

Ein Trigger feuert bei großen Bestellungen, und der Agent postet eine Risikoeinschätzung in deinen Ops-Channel in Slack.

Große Bestellung
Postgres Inbound
order-reviewer
Notiz in Slack
payload.json
{
  "order_id": "ord_8812",
  "customer_id": "cus_4102",
  "total_cents": 489000,
  "first_order": true,
  "_postgres": {
    "channel": "large_orders",
    "pid": 48213,
    "timestamp": "2026-10-13T09:00:00.123456"
  }
}
connector-payload.json
{
  "text": "ord_8812: 4,890 EUR, first order, new address. Check first.",
  "channel_id": "C01234567"
}

Jeder neue Kommentar wird geprüft, und ein ausgehender Webhook schickt das Ergebnis an deine Moderations-API.

Neuer Kommentar
Postgres Inbound
comment-moderator
Ergebnis an deine API
payload.json
{
  "comment_id": "cm_5530",
  "post_id": "post_771",
  "body": "Great guide, but step 3 links to a dead page.",
  "_postgres": {
    "channel": "new_comments",
    "pid": 48213,
    "timestamp": "2026-10-13T09:00:00.123456"
  }
}
outbound-payload.json
{
  "run_id": "550e8400-e29b-41d4-a716-446655440000",
  "agent_name": "comment-moderator",
  "status": "completed",
  "output": "Approved. No policy issues, reports a broken link in step 3.",
  "error": null,
  "started_at": "2026-10-13T09:00:00Z",
  "ended_at": "2026-10-13T09:00:05Z",
  "token_usage": {
    "input_tokens": 640,
    "output_tokens": 48,
    "thinking_tokens": 0,
    "cached_input_tokens": 0,
    "total_tokens": 688
  }
}

Ein Update-Trigger sendet alten und neuen Status, und der Agent schreibt dem Kontoinhaber eine E-Mail, wenn eine Zahlung überfällig ist.

Statuswechsel
Postgres Inbound
account-notifier
E-Mail an den Inhaber
payload.json
{
  "operation": "UPDATE",
  "account_id": "acc_2207",
  "old_status": "active",
  "new_status": "past_due",
  "_postgres": {
    "channel": "account_status",
    "pid": 48213,
    "timestamp": "2026-10-13T09:00:00.123456"
  }
}
connector-payload.json
{
  "to": "owner@example.com",
  "subject": "Your payment is past due",
  "body": "The last payment for acc_2207 failed. Please update your card."
}

FAQ zu PostgreSQL

Schreib eine Trigger-Funktion, die pg_notify() mit einer JSON-Payload aufruft, hänge sie mit AFTER INSERT an die Tabelle und richte eine PostgreSQL-Verbindung auf diesen Channel aus. Jeder Insert startet dann einen Run mit der Payload. AFTER UPDATE und AFTER DELETE funktionieren genauso. Beispiele für Inserts und Updates findest du in der PostgreSQL-Dokumentation.

Nein. Sie hält eine dauerhafte Datenbankverbindung, lauscht auf dem Channel und wartet, bis PostgreSQL Notifications schickt. Abgesehen von einer Verbindungsprüfung alle 30 Sekunden sendet sie keine Abfragen.

Ja. Leite die Verbindung über eine connic Bridge in deinem Netzwerk. Die Bridge baut nur ausgehende Verbindungen auf, deine Datenbank braucht also weder eine öffentliche Adresse noch eine eingehende Firewall-Regel.

Sie gehen verloren. PostgreSQL hebt Notifications für einen Listener ohne aktive Datenbankverbindung nicht auf, nach dem Fortsetzen wird also nichts nachgeholt. Die maßgeblichen Daten gehören deshalb in deine Tabellen.

PostgreSQL begrenzt NOTIFY-Payloads auf 8000 Bytes. Sende die ID der Zeile und die Felder, die der Agent für seine Entscheidung braucht, und lass ihn den Rest über ein Tool laden.