Ограничение за изключване на колона от битов низ с побитов оператор И

CREATE EXTENSION btree_gist;

Класовете оператори, инсталирани от btree_gist обхваща много оператори. За съжаление, & оператор не е сред тях. Очевидно, защото не връща булева стойност което би се очаквало от оператора да отговаря на изискванията.

Алтернативно решение

Бих използвал комбинация от b-дърво многоколонен индекс (за скорост) и спусък вместо. Помислете за тази демонстрация, тествана на PostgreSQL 9.1 :

CREATE TABLE t (
  name text 
 ,value bit(8)
);

INSERT INTO t VALUES ('a', B'10101010'); 

CREATE INDEX t_name_value_idx ON t (name, value);

CREATE OR REPLACE FUNCTION trg_t_name_value_inversion_prohibited()
  RETURNS trigger AS
$func$
BEGIN
IF EXISTS (
     SELECT 1 FROM t
     WHERE (name, value) = (NEW.name, ~ NEW.value)  -- example: exclude inversion
     ) THEN

    RAISE EXCEPTION 'Your text here!';
END IF;

RETURN NEW;
END
$func$ LANGUAGE plpgsql;

CREATE TRIGGER insup_bef_t_name_value_inversion_prohibited
BEFORE INSERT OR UPDATE OF name, value  -- only involved columns relevant!
ON t
FOR EACH ROW
EXECUTE PROCEDURE trg_t_name_value_inversion_prohibited();

INSERT INTO t VALUES ('a', ~ B'10101010');  -- fails with your error msg.

• ~ е операторът за инверсия .

• Разширението btree_gist е не се изисква в този сценарий.

• Ограничих тригера до INSERT или UPDATE на съответните колони за ефективност.

• Ограничение за проверка нямаше да работи. Цитирам ръководството за CREATE TABLE :

  Удебеленият акцент е мой:

Трябва да работи много добре, всъщност по-добре от ограничението за изключване, тъй като поддръжката на индекс на b-дърво е по-евтина от GiST индекс. И търсенето с основен = операторите трябва да са по-бързи от хипотетичните търсения с & оператор.

Това решение не е толкова безопасно, колкото ограничението за изключване, тъй като задействанията могат по-лесно да бъдат заобиколени - например при следващо задействане при същото събитие или ако задействането е временно деактивирано. Бъдете готови да извършите допълнителни проверки на цялата таблица, ако са приложими такива условия.

По-сложно условие

Примерният тригер улавя само инверсията на value . Както изяснихте в коментара си, вместо това всъщност се нуждаете от условие като това:

IF EXISTS (
      SELECT 1 FROM t
      WHERE  name = NEW.name
      AND    value & NEW.value <> B'00000000'::bit(8)
      ) THEN

Това условие е малко по-скъпо, но все още може да използва индекс. Индексът с много колони от по-горе ще работи - ако все пак имате нужда от него. Или, малко по-ефективно, прост индекс на име:

CREATE INDEX t_name_idx ON t (name);

Както коментирахте, може да има максимум 8 отделни реда на име , по-малко на практика. Така че това все още трябва да е бързо.

Върховна производителност на INSERT

Ако INSERT производителността е от първостепенно значение, особено ако много опити за INSERT не изпълнят условието, бихте могли да направите повече:създайте материализиран изглед, който предварително агрегира стойност на име :

CREATE TABLE mv_t AS 
SELECT name, bit_or(value) AS value
FROM   t
GROUP  BY 1
ORDER  BY 1;

име е гарантирано уникален тук. Бих използвал PRIMARY KEY на име за да предоставим индекса, който търсим:

ALTER TABLE mv_t SET (fillfactor=90);

ALTER TABLE mv_t
ADD CONSTRAINT mv_t_pkey PRIMARY KEY(name) WITH (fillfactor=90);

След това вашият INSERT може да изглежда така:

WITH i(n,v) AS (SELECT 'a'::text, B'10101010'::bit(8)) 
INSERT INTO t (name, value)
SELECT n, v
FROM   i
LEFT   JOIN mv_t m ON m.name = i.n
                  AND m.value & i.v <> B'00000000'::bit(8)
WHERE  m.n IS NULL;          -- alternative syntax for EXISTS (...)

fillfactor е полезно само ако вашата таблица получава много актуализации.

Актуализирайте редовете в материализирания изглед в ТРИМЕР СЛЕД ВМЪКВАНЕ ИЛИ АКТУАЛИЗИРАНЕ НА име, стойност ИЛИ ИЗТРИВАНЕ за да го поддържате актуален. Цената на допълнителните обекти трябва да се претегли спрямо печалбата. До голяма степен зависи от вашето типично натоварване.