Check Contraint Verstoß mit Array

Hi,
ich hab ein Problem mit einem Check in einer variable character()[]-Spalte, siehe unten. Ohne Constraint lässt sich das INSERT ausführen - mit Constraint nicht. Das Constraint lässt sich auch ohne zu murren eingeben. Ich hab das leider noch nie gemacht und mich an ein Beispiel gehalten. Woran kanns liegen?

CREATE TABLE lebmitt (
...
  typ character varying(20)[],
...
)

alter table lebmitt
add CONSTRAINT check_typ CHECK (typ::text = ANY (ARRAY[
  ...
  'natürlich'::character varying,
  'milchsauer vergoren'::character varying,
  ...
  ]::text[]));

INSERT INTO lebmitt
  (..., typ, ...)
  VALUES (
    ...,
    '{"natürlich", "milchsauer vergoren"}',
    ...);

ERROR: FEHLER: neue Zeile für Relation »lebmitt« verletzt Check-Constraint »check_typ«
DETAIL: Fehlgeschlagene Zeile enthält (…, {natürlich,“milchsauer vergoren”}, …).

Danke!

was genau ist jetzt das Problem? Das arbeitet wie vorgegeben. Der Check Constraint ist da, um bestimmte Eingaben nichtanzunehmen.

ahh, ich glaube, Du suchst sowas hier:

test=*# create table lebmitt(type text[], check (type <@ array['natürlich','milchsauer vergoren']));
CREATE TABLE
test=*# 
test=*# 
test=*# INSERT INTO lebmitt VALUES (array['natürlich']);
INSERT 0 1
test=*# INSERT INTO lebmitt VALUES (array['milchsauer vergoren']);
INSERT 0 1
test=*# INSERT INTO lebmitt VALUES (array['Bier']);
ERROR:  new row for relation "lebmitt" violates check constraint "lebmitt_type_check"
DETAIL:  Failing row contains ({Bier}).
test=*#

hilft das weiter?

Abgesehen davon, dass es krass ist, was mit postgres alles geht, würde ich so ein Vorgehen nicht empfehlen.
Zumindest macht es bei den genannten Werten und der zu erwartenden Nutzung wahrscheinlich keinen Sinn.

Anhand der angegebenen Werte würde ich davon ausgehen, dass es neben den beiden genannten Beispielen weitere mögliche Werte gibt. Was erstmal okay ist.
Ich würde aber auch davon ausgehen, dass es übermorgen weitere derartige Werte gibt.
Diese Änderungen im inhaltlichen Bereich erfordern bei dem gewählten Vorgehen immer ein Alter Table Befehl. Alter Tables sind eine Änderung des Datenmodels und haben eine Reihe von Implikationen. Neben der Problematik, dass abhängige Objekte betroffen sein könnten, gibt es aber auch inhaltliche Probleme bei derartigen Constraints. Das Vorgehen wäre ein konzeptioneller Fehler.

Um noch anders deutlich zu machen, wo ich das Problem sehe:
Geht es bspw. um den Lebenszyklus einer Bestellung [‘neu’, ‘bestätigt’, ‘kommisioniert’, ‘verschickt’, ‘angekommen’, ‘bewertet’], ist nicht zu erwarten, dass es häufige Änderungen gibt. Dies würde erst geschehen, bei neuen Workflows mit geänderten Implementierungen. Also ein legitimes Vorgehen und ein Gegenbeispiel zu der Aufgabenstellung des TE, wohlgemerkt, rein inhaltlich.

Ich würde das auch nicht mit einem Array machen, sondern sauber normalisieren. Wenn ein Lebensmittel wirklich mehr als einen Typ haben kann, dann sollte man das als sog. many-to-many Beziehung modellieren.

Nein, wäre es nicht.
Es ist fast immer die bessere Strategie zuerst mit einem sauber normalisierten Modell anzufangen, und erst wenn es damit wirklich Probleme gibt, sich über de-Normalisierung Gedanken zu machen.