Deferred Unique Constraint using a Function-based Index? - sql

I think this will be a bit esoteric but wanted to throw this out there in case anyone's tried anything like this, or if someone's already tried and found it to be impossible.
We have a table that needs a uniqueness constraint on a certain set of columns, but it also has a "soft delete" indicator. Records that have been marked as "deleted" should not be included in the uniqueness check.
That's all fine, I could solve this easily with a unique function-based index. However, what complicates matters is that if we're going to implement this constraint in the database, it must be a deferred constraint, because of the way Hibernate works. If it can't be done, we'll have to omit the constraint, and I'd prefer not to if at all possible.
For example:
CREATE TABLE jkemp_test
( id NUMBER NOT NULL
, deleted_ind CHAR(1) DEFAULT 'N' NOT NULL);
CREATE UNIQUE INDEX jkemp_test_funique
ON jkemp_test
(CASE WHEN deleted_ind = 'N' THEN id END);
-- make this use the function-based index, maybe?
ALTER TABLE jkemp_test
ADD CONSTRAINT jkemp_test_unique
UNIQUE (id)
DEFERRABLE INITIALLY DEFERRED;
INSERT INTO jkemp_test VALUES (1,'N');
INSERT INTO jkemp_test VALUES (2,'N');
COMMIT;
UPDATE jkemp_test SET deleted_ind='Y' WHERE id=1;
COMMIT;
-- depending on whether the constraint is deferred or not, either
-- the insert or the commit will fail "unique constraint violated"
INSERT INTO jkemp_test VALUES (1,'N');
COMMIT;
A win-win scenario would be for the last commit to succeed, while still allowing the constraint to be deferred. (I'm aware that the existence of the unique index means that the constraint is not currently deferred.)
Our only option at the moment is to implement the constraint using the application, which will not be as reliable. Also, we don't want to change the data model too much (e.g. we could move the deleted rows to a different table, e.g. JKEMP_TEST_DELETED, but that would involve too much complication in the application).
This is on Oracle 11.2.0.1.0.

This works in the 11.2.0.2 behind apex.oracle.com. It SHOULD work in 11.2.0.1 (and maybe in 11.1, but not in 10g as virtual colums were an 11g enhancement)
Credit to Lucas Jellma
CREATE TABLE jkemp_test
( id NUMBER NOT NULL
, deleted_ind CHAR(1) DEFAULT 'N' NOT NULL);
alter table jkemp_test
ADD (active_id AS (CASE WHEN deleted_ind = 'N' THEN id END))
/
ALTER TABLE jkemp_test
ADD CONSTRAINT jkemp_test_unique
UNIQUE (active_id)
DEFERRABLE INITIALLY DEFERRED;
You do have to specify the column list for the inserts, as the derived column (virtual column) shouldn't be specified. I'm pretty sure that hibernate is fine with having columns it doesn't touch.
INSERT INTO jkemp_test (id, deleted_ind) VALUES (1,'N');
INSERT INTO jkemp_test (id, deleted_ind) VALUES (2,'N');
COMMIT;
UPDATE jkemp_test SET deleted_ind='Y' WHERE id=1;
COMMIT;
INSERT INTO jkemp_test (id, deleted_ind) VALUES (1,'N');

Jeff,
Here is one way to implement the requirement that would work in versions prior to 11g also.
DROP MATERIALIZED VIEW MV_JKEMP ;
DROP MATERIALIZED VIEW LOG ON jkemp_test ;
DROP TABLE JKEMP_TEST ;
CREATE TABLE jkemp_test
( id NUMBER NOT NULL
, deleted_ind CHAR(1) DEFAULT 'N' NOT NULL);
CREATE MATERIALIZED VIEW LOG ON jkemp_test WITH ROWID ;
CREATE MATERIALIZED VIEW MV_JKEMP
REFRESH FAST ON COMMIT
AS
SELECT JT1.ROWID r1, JT2.ROWID r2
FROM JKEMP_TEST JT1, JKEMP_TEST JT2
WHERE JT1.ID = JT2.ID
AND JT1.DELETED_IND = JT2.DELETED_IND
AND JT1.ROWID != JT2.ROWID
AND JT1.DELETED_IND = 'N' ;
ALTER TABLE MV_JKEMP ADD CONSTRAINT MV_CHECK CHECK (R1 IS NULL OR R2 IS NULL)
INSERT INTO jkemp_test VALUES (1,'N');
INSERT INTO jkemp_test VALUES (2,'N');
COMMIT;
UPDATE jkemp_test SET deleted_ind='Y' WHERE id=1 AND deleted_ind = 'N';
COMMIT;
SELECT * FROM JKEMP_TEST ;
SELECT * FROM MV_JKEMP;
INSERT INTO JKEMP_TEST VALUES (1,'N');
COMMIT;
SELECT * FROM JKEMP_TEST ;
SELECT * FROM MV_JKEMP;
-- The following will succeed on the INSERT but fail on COMMIT
INSERT INTO JKEMP_TEST VALUES (1,'N');
COMMIT;
-- The following will succeed
INSERT INTO JKEMP_TEST VALUES (3,'N');
COMMIT;
SELECT * FROM JKEMP_TEST ;
SELECT * FROM MV_JKEMP;
-- The following will succeed
UPDATE JKEMP_TEST SET DELETED_IND='Y' WHERE ID=1 AND DELETED_IND = 'N';
COMMIT;
SELECT * FROM JKEMP_TEST ;
SELECT * FROM MV_JKEMP;
DELETE FROM JKEMP_TEST ;
COMMIT;
The above was tested on 10.2.0.1.

Related

Create a Trigger with merge to monitor tables

I need to create a Trigger to monitor this table :
CREATE TABLE "REFERENCE"
( "NUM_CONTRACT" VARCHAR2(20 CHAR),
"NATURE" VARCHAR2(20 CHAR),
"PR" VARCHAR2(14 CHAR),
)
I just want to store the date of the last modification and his "PR" in this table :
CREATE TABLE EVENT_REFERENCE (
ID NUMBER GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1) NOT NULL,
reference VARCHAR(14) NOT NULL UNIQUE,
date_modification TIMESTAMP(6),
PRIMARY KEY (ID)
)
I use a merge in order to avoid to have duplicate rows with the same reference and different date . I just want to keep the date of last modification for each reference rows
For that i created this trigger but idk what's wrong with it . Can anyone help me ?
CREATE OR REPLACE TRIGGER TRG_REFERENCE
AFTER INSERT OR UPDATE ON REFERENCE
FOR EACH ROW
DECLARE
PRAGMA autonomous_transaction;
BEGIN
IF INSERTING
THEN
MERGE INTO EVENT_REFERENCE hist
USING (select :new.pr
from dual) t1
ON (t1.pr=hist.reference)
WHEN MATCHED THEN
UPDATE SET hist.date_modification=systimestamp
WHEN NOT MATCHED THEN
INSERT INTO EVENT_REFERENCE (REFERENCE, DATE_MODIFICATION)
VALUES (:NEW.prm, systimestamp);
END IF;
COMMIT;
END;
You have:
:NEW.prm when it should be :NEW.pr
INSERT INTO EVENT_REFERENCE (REFERENCE, DATE_MODIFICATION) when you just need INSERT (REFERENCE, DATE_MODIFICATION)
You also use AFTER INSERT OR UPDATE and then check IF INSERTING why not just use AFTER INSERT?
The fixed code:
CREATE OR REPLACE TRIGGER TRG_REFERENCE
AFTER INSERT OR UPDATE ON REFERENCE
FOR EACH ROW
DECLARE
PRAGMA autonomous_transaction;
BEGIN
IF INSERTING
THEN
MERGE INTO EVENT_REFERENCE hist
USING DUAL t1
ON (:new.pr=hist.reference)
WHEN MATCHED THEN
UPDATE SET hist.date_modification=systimestamp
WHEN NOT MATCHED THEN
INSERT (REFERENCE, DATE_MODIFICATION)
VALUES (:NEW.pr, systimestamp);
END IF;
COMMIT;
END;
/
db<>fiddle here

Oracle masking data using a trigger

Im trying to create a process that masks data. When I create the trigger I'm getting the error.
ORA-04072: invalid trigger type
I'm unsure why and was hoping someone can explain what the problem is and how to fix it.
The end result is when a user queries cards they should see the masked data and WHEN they query CARDS_TBL they should see all the data (unmasked)
Original implementation
CREATE TABLE CARDS (
CARD_ID NUMBER
GENERATED BY DEFAULT AS IDENTITY,
CARD_STR VARCHAR2(16) NOT NULL,
PRIMARY KEY (CARD_ID)
);
INSERT INTO CARDS(CARD_STR) VALUES('4024007187788590');
INSERT INTO CARDS(CARD_STR) VALUES('5432223398564536');
INSERT INTO CARDS(CARD_STR) VALUES('5430445512530934');
INSERT INTO CARDS(CARD_STR) VALUES('4020156755227854');
INSERT INTO CARDS(CARD_STR) VALUES('5431248766892318');
CREATE OR REPLACE VIEW CARDS_V AS
SELECT
CARD_ID,
REGEXP_REPLACE(CARD_STR, '(^\d{3})(.*)(\d{4}$)', '\1**********\3') AS CARD_STR
FROM CARDS;
CREATE OR REPLACE TRIGGER CARDS_TRG_INSERT INSTEAD OF
INSERT ON CARDS_V
FOR EACH ROW
BEGIN
INSERT INTO CARDS (CARD_STR) VALUES (:NEW.CARD_STR);
END;
INSERT INTO CARDS_V (CARD_STR) VALUES ('4011589733550908');
CREATE OR REPLACE TRIGGER CARDS_TRG_UPDATE INSTEAD OF
UPDATE ON CARDS_V
FOR EACH ROW
BEGIN
UPDATE CARDS
SET CARD_STR = :NEW.CARD_STR
WHERE CARD_ID = :OLD.CARD_ID;
END;
CREATE TABLE CARDS_TBL (
CARD_ID NUMBER
GENERATED BY DEFAULT AS IDENTITY,
CARD_STR VARCHAR2(16) NOT NULL,
PRIMARY KEY (CARD_ID)
);
INSERT INTO CARDS_TBL(CARD_STR) VALUES('4024007187788590');
INSERT INTO CARDS_TBL(CARD_STR) VALUES('5432223398564536');
INSERT INTO CARDS_TBL(CARD_STR) VALUES('5430445512530934');
INSERT INTO CARDS_TBL(CARD_STR) VALUES('4020156755227854');
INSERT INTO CARDS_TBL(CARD_STR) VALUES('5431248766892318');
CREATE OR REPLACE VIEW CARDS AS
SELECT
CARD_ID,
REGEXP_REPLACE(CARD_STR, '(^\d{3})(.*)(\d{4}$)', '\1**********\3') AS CARD_STR
FROM CARDS_TBL;
CREATE OR REPLACE TRIGGER CARDS_TBL_TRG_UPDATE BEFORE UPDATE ON CARDS_TBL
FOR EACH ROW
BEGIN
UPDATE CARDS_TBL
SET CARD_STR = :NEW.CARD_STR
WHERE CARD_ID = :OLD.CARD_ID;
END;
/
CREATE OR REPLACE TRIGGER CARDS_TBL_TRG_INSERT BEFORE INSERT ON CARDS
FOR EACH ROW
BEGIN
INSERT INTO CARDS_TBL (CARD_STR) VALUES (:NEW.CARD_STR);
END;
INSERT INTO CARDS_TBL (CARD_STR) VALUES ('2222333344445555');
SELECT * FROM CARDS_TBL;
UPDATE CARDS_TBL
SET CARD_STR = '2222333344445566'
WHERE CARD_ID = 6;
/
SELECT * FROM CARDS;
In this particular example, at least, the trigger CARDS_TBL_TRG_UPDATE doesn't do anything (except raise a MUTATING TABLE exception) and can be dispensed with. Get rid of it and your example runs as expected. See this db<>fiddle

Oracle SQL - Trigger inserting into table passing null value from sequence

I have two table, TABLE_A and TABLE_B. When something gets inserted into TABLE_A there is a trigger that also inserts the data into TABLE_B. TABLE_A has an ID column which is populated using a sequence. This id then is also inserted into TABLE_B. This is the whole DDL for this:
CREATE TABLE "TABLE_A"
( "ID" NUMBER(8,0) NOT NULL ENABLE,
"COLUMN1" NUMBER(8,0) NOT NULL ENABLE,
"COLUMN2" NUMBER(4,0) NOT NULL ENABLE
)
/
CREATE TABLE "TABLE_B"
( "ID" NUMBER(8,0) NOT NULL ENABLE,
"COLUMN1" NUMBER(8,0) NOT NULL ENABLE,
"COLUMN2" NUMBER(4,0) NOT NULL ENABLE
)
/
CREATE UNIQUE INDEX "AID_PK" ON "TABLE_A" ("ID")
/
ALTER TABLE "TABLE_A" ADD CONSTRAINT "AID_PK" PRIMARY KEY ("ID")
USING INDEX "AID_PK" ENABLE
/
create or replace TRIGGER my_trigger
BEFORE INSERT OR UPDATE OR DELETE ON TABLE_A
FOR EACH ROW
BEGIN
IF INSERTING THEN
INSERT INTO TABLE_B(
ID,
COLUMN1,
COLUMN2)
VALUES(
:new.ID,
:new.COLUMN1,
:new.COLUMN2);
END IF;
END;
/
ALTER TRIGGER "my_trigger" ENABLE
/
CREATE SEQUENCE "MY_SEQ" MINVALUE 1 MAXVALUE 999999999999999 INCREMENT BY 1 START WITH 5002 CACHE 20 NOORDER NOCYCLE NOKEEP NOSCALE GLOBAL;
/
CREATE OR REPLACE EDITIONABLE TRIGGER "MYSEQ_SEQ_IOT"
before insert on table_a
for each row
begin
select MY_SEQ.nextval into :new.id from dual;
end;
/
ALTER TRIGGER "MYSEQ_SEQ_IOT" ENABLE
/
Now when I run this statement:
INSERT INTO PER_ART(
COLUMN1,
COLUMN2
)
VALUES(
1111111,
2222222);
I get this error:
ORA-01400: cannot insert NULL into ("TABLE_B"."ID")
ORA-06512: at "my_trigger", line 7
ORA-04088: error during execution of trigger 'my_trigger'
Why is the ID null when the sequence should be populating it?
The order in which your two triggers fire is indeterminate. In my opinion, the best solution would be to just use one trigger:
create or replace TRIGGER my_trigger
BEFORE INSERT ON TABLE_A
FOR EACH ROW
BEGIN
select MY_SEQ.nextval
into :new.id
from dual;
INSERT INTO TABLE_B(
ID,
COLUMN1,
COLUMN2)
VALUES(
:new.ID, -- Or use MY_SEQ.curreval
:new.COLUMN1,
:new.COLUMN2);
END;
If you must have two triggers for some reason, then you can control their firing order using the FOLLOWS and PRECEDES clauses of the CREATE TRIGGER statement. Refer to the documentation for details on controlling trigger order.

PostgreSQL constraint using prefixes

Let's say I have the following PostgreSQL table:
id | key
---+--------
1 | 'a.b.c'
I need to prevent inserting records with a key that is a prefix of another key. For example, I should be able to insert:
'a.b.b'
But the following keys should not be accepted:
'a.b'
'a.b.c'
'a.b.c.d'
Is there a way to achieve this - either by a constraint or by a locking mechanism (check the existance before inserting)?
This solution is based on PostgreSQL user-defined operators and exclusion constraints (base syntax, more details).
NOTE: more testing shows this solution does not work (yet). See bottom.
Create a function has_common_prefix(text,text) which will calculate logically what you need. Mark the function as IMMUTABLE.
CREATE OR REPLACE FUNCTION
has_common_prefix(text,text)
RETURNS boolean
IMMUTABLE STRICT
LANGUAGE SQL AS $$
SELECT position ($1 in $2) = 1 OR position ($2 in $1) = 1
$$;
Create an operator for the index
CREATE OPERATOR <~> (
PROCEDURE = has_common_prefix,
LEFTARG = text,
RIGHTARG = text,
COMMUTATOR = <~>
);
Create exclusion constraint
CREATE TABLE keys ( key text );
ALTER TABLE keys
ADD CONSTRAINT keys_cannot_have_common_prefix
EXCLUDE ( key WITH <~> );
However, the last point produces this error:
ERROR: operator <~>(text,text) is not a member of operator family "text_ops"
DETAIL: The exclusion operator must be related to the index operator class for the constraint.
This is because to create an index PostgreSQL needs logical operators to be bound with physical indexing methods, via entities calles "operator classes". So we need to provide that logic:
CREATE OR REPLACE FUNCTION keycmp(text,text)
RETURNS integer IMMUTABLE STRICT
LANGUAGE SQL AS $$
SELECT CASE
WHEN $1 = $2 OR position ($1 in $2) = 1 OR position ($2 in $1) = 1 THEN 0
WHEN $1 < $2 THEN -1
ELSE 1
END
$$;
CREATE OPERATOR CLASS key_ops FOR TYPE text USING btree AS
OPERATOR 3 <~> (text, text),
FUNCTION 1 keycmp (text, text)
;
ALTER TABLE keys
ADD CONSTRAINT keys_cannot_have_common_prefix
EXCLUDE ( key key_ops WITH <~> );
Now, it works:
INSERT INTO keys SELECT 'ara';
INSERT 0 1
INSERT INTO keys SELECT 'arka';
INSERT 0 1
INSERT INTO keys SELECT 'barka';
INSERT 0 1
INSERT INTO keys SELECT 'arak';
psql:test.sql:44: ERROR: conflicting key value violates exclusion constraint "keys_cannot_have_common_prefix"
DETAIL: Key (key)=(arak) conflicts with existing key (key)=(ara).
INSERT INTO keys SELECT 'bark';
psql:test.sql:45: ERROR: conflicting key value violates exclusion constraint "keys_cannot_have_common_prefix"
DETAIL: Key (key)=(bark) conflicts with existing key (key)=(barka).
NOTE: more testing shows this solution does not work yet: The last INSERT should fail.
INSERT INTO keys SELECT 'a';
INSERT 0 1
INSERT INTO keys SELECT 'ac';
ERROR: conflicting key value violates exclusion constraint "keys_cannot_have_common_prefix"
DETAIL: Key (key)=(ac) conflicts with existing key (key)=(a).
INSERT INTO keys SELECT 'ab';
INSERT 0 1
You can use ltree module to achieve this, it will let you to create hierarchical tree-like structures. Also will help you to prevent from reinventing the wheel, creating complicated regular expressions and so on. You just need to have postgresql-contrib package installed. Take a look:
--Enabling extension
CREATE EXTENSION ltree;
--Creating our test table with a pre-loaded data
CREATE TABLE test_keys AS
SELECT
1 AS id,
'a.b.c'::ltree AS key_path;
--Now we'll do the trick with a before trigger
CREATE FUNCTION validate_key_path() RETURNS trigger AS $$
BEGIN
--This query will do our validation.
--It'll search if a key already exists in 'both' directions
--LIMIT 1 because one match is enough for our validation :)
PERFORM * FROM test_keys WHERE key_path #> NEW.key_path OR key_path <# NEW.key_path LIMIT 1;
--If found a match then raise a error
IF FOUND THEN
RAISE 'Duplicate key detected: %', NEW.key_path USING ERRCODE = 'unique_violation';
END IF;
--Great! Our new row is able to be inserted
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER test_keys_validator BEFORE INSERT OR UPDATE ON test_keys
FOR EACH ROW EXECUTE PROCEDURE validate_key_path();
--Creating a index to speed up our validation...
CREATE INDEX idx_test_keys_key_path ON test_keys USING GIST (key_path);
--The command below will work
INSERT INTO test_keys VALUES (2, 'a.b.b');
--And the commands below will fail
INSERT INTO test_keys VALUES (3, 'a.b');
INSERT INTO test_keys VALUES (4, 'a.b.c');
INSERT INTO test_keys VALUES (5, 'a.b.c.d');
Of course I did not bother creating primary key and other constraints for this test. But do not forget to do so. Also, there is much more on ltree module than I'm showing, if you need something different take a look on its docs, perhaps you'll find the answer there.
You can try below trigger. Please note that key is sql reserve word. So I would suggest you avoid using that as column name in your table.
I have added my create table syntax also for testing purpose:
CREATE TABLE my_table
(myid INTEGER, mykey VARCHAR(50));
CREATE FUNCTION check_key_prefix() RETURNS TRIGGER AS $check_key_prefix$
DECLARE
v_match_keys INTEGER;
BEGIN
v_match_keys = 0;
SELECT COUNT(t.mykey) INTO v_match_keys
FROM my_table t
WHERE t.mykey LIKE CONCAT(NEW.mykey, '%')
OR NEW.mykey LIKE CONCAT(t.mykey, '%');
IF v_match_keys > 0 THEN
RAISE EXCEPTION 'Prefix Key Error occured.';
END IF;
RETURN NEW;
END;
$check_key_prefix$ LANGUAGE plpgsql;
CREATE TRIGGER check_key_prefix
BEFORE INSERT OR UPDATE ON my_table
FOR EACH ROW
EXECUTE PROCEDURE check_key_prefix();
Here is a CHECK - based solution - it may satisfy your needs.
CREATE TABLE keys ( id serial primary key, key text );
CREATE OR REPLACE FUNCTION key_check(text)
RETURNS boolean
STABLE STRICT
LANGUAGE SQL AS $$
SELECT NOT EXISTS (
SELECT 1 FROM keys
WHERE key ~ ( '^' || $1 )
OR $1 ~ ( '^' || key )
);
$$;
ALTER TABLE keys
ADD CONSTRAINT keys_cannot_have_common_prefix
CHECK ( key_check(key) );
PS. Unfortunately, it fails in one point (multi - row inserts).
SQL is a very powerful language. Usually you can do most of the things by plain select statements. I.e. if you do not like triggers, you can use a this method for your inserts.
The only assumption is there exists at least 1 row in the table. (*)
The table:
create table my_table
(
id integer primary key,
key varchar(100)
);
Because of the assumption, we'll have at least 1 row.(*)
insert into my_table (id, key) values (1, 'a.b.c');
Now the magic sql. The trick is replace the p_key value by your key value to insert. I have, intentionally, not put that statement into a stored procedure. Because I want it to be straight forward if you want to carry it to your application side. But usually putting sql into stored procedure is better.
insert into my_table (id, key)
select (select max(id) + 1 from my_table), p_key
from my_table
where not exists (select 'p' from my_table where key like p_key || '%' or p_key like key || '%')
limit 1;
Now the tests:
-- 'a.b.b' => Inserts
insert into my_table (id, key)
select (select max(id) + 1 from my_table), 'a.b.b'
from my_table
where not exists (select 'p' from my_table where key like 'a.b.b' || '%' or 'a.b.b' like key || '%')
limit 1;
-- 'a.b' => does not insert
insert into my_table (id, key)
select (select max(id) + 1 from my_table), 'a.b'
from my_table
where not exists (select 'p' from my_table where key like 'a.b' || '%' or 'a.b' like key || '%')
limit 1;
-- 'a.b.c' => does not insert
insert into my_table (id, key)
select (select max(id) + 1 from my_table), 'a.b.c'
from my_table
where not exists (select 'p' from my_table where key like 'a.b.c' || '%' or 'a.b.c' like key || '%')
limit 1;
-- 'a.b.c.d' does not insert
insert into my_table (id, key)
select (select max(id) + 1 from my_table), 'a.b.c.d'
from my_table
where not exists (select 'p' from my_table where key like 'a.b.c.d' || '%' or 'a.b.c.d' like key || '%')
limit 1;
(*) If you wish you can get rid of this existence of the single row by introducing an Oracle like dual table. If you wish modifying the insert statement is straight forward. Let me know if you wish to do so.
One possible solution is to create a secondary table that holds the prefixes of your keys, and then use a combination of unique and exclusion constraints with an insert trigger to enforce the uniqueness semantics you want.
At a high level, this approach breaks each key down into a list of prefixes and applies something similar to readers-writer lock semantics: any number of keys may share a prefix as long as none of the keys equals the prefix. To accomplish that, the list of prefixes includes the key itself with a flag that marks it as a terminal prefix.
The secondary table looks like this. We use a CHAR rather than a BOOLEAN for the flag because later on we’ll be adding a constraint that doesn’t work on boolean columns.
CREATE TABLE prefixes (
id INTEGER NOT NULL,
prefix TEXT NOT NULL,
is_terminal CHAR NOT NULL,
CONSTRAINT prefixes_id_fk
FOREIGN KEY (id)
REFERENCES your_table (id)
ON DELETE CASCADE,
CONSTRAINT prefixes_is_terminal
CHECK (is_terminal IN ('t', 'f'))
);
Now we’ll need to define a trigger on insert into your_table to also insert rows into prefixes, such that
INSERT INTO your_table (id, key) VALUES (1, ‘abc');
causes
INSERT INTO prefixes (id, prefix, is_terminal) VALUES (1, 'a', ‘f’);
INSERT INTO prefixes (id, prefix, is_terminal) VALUES (1, 'ab', ‘f’);
INSERT INTO prefixes (id, prefix, is_terminal) VALUES (1, 'abc', ’t’);
The trigger function might look like this. I’m only covering the INSERT case here, but the function could be made to handle UPDATE as well by deleting the old prefixes and then inserting the new ones. The DELETE case is covered by the cascading foreign-key constraint on prefixes.
CREATE OR REPLACE FUNCTION insert_prefixes() RETURNS TRIGGER AS $$
DECLARE
is_terminal CHAR := 't';
remaining_text TEXT := NEW.key;
BEGIN
LOOP
IF LENGTH(remaining_text) <= 0 THEN
EXIT;
END IF;
INSERT INTO prefixes (id, prefix, is_terminal)
VALUES (NEW.id, remaining_text, is_terminal);
is_terminal := 'f';
remaining_text := LEFT(remaining_text, -1);
END LOOP;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
We add this function to the table as a trigger in the usual way.
CREATE TRIGGER insert_prefixes
AFTER INSERT ON your_table
FOR EACH ROW
EXECUTE PROCEDURE insert_prefixes();
An exclusion constraint and a partial unique index will enforce that a row where is_terminal = ’t’ can't collide with another row of the same prefix regardless of its is_terminal value, and that there's only one row with is_terminal = ’t’:
ALTER TABLE prefixes ADD CONSTRAINT prefixes_forbid_conflicts
EXCLUDE USING gist (prefix WITH =, is_terminal WITH <>);
CREATE UNIQUE INDEX ON prefixes (prefix) WHERE is_terminal = 't';
This allows new rows that don’t conflict but prevents ones that do conflict, including in multi-row INSERTs.
db=# INSERT INTO your_table (id, key) VALUES (1, 'a.b.c');
INSERT 0 1
db=# INSERT INTO your_table (id, key) VALUES (2, 'a.b.b');
INSERT 0 1
db=# INSERT INTO your_table (id, key) VALUES (3, 'a.b');
ERROR: conflicting key value violates exclusion constraint "prefixes_forbid_conflicts"
db=# INSERT INTO your_table (id, key) VALUES (4, 'a.b.c');
ERROR: duplicate key value violates unique constraint "prefixes_prefix_idx"
db=# INSERT INTO your_table (id, key) VALUES (5, 'a.b.c.d');
ERROR: conflicting key value violates exclusion constraint "prefixes_forbid_conflicts"
db=# INSERT INTO your_table (id, key) VALUES (6, 'a.b.d'), (7, 'a');
ERROR: conflicting key value violates exclusion constraint "prefixes_forbid_conflicts"

Constraint on values, oracle database

I would like to have a table in my Oracle database where the values of an attribute1 (values may change) can't be greater than the value (fixed) of attribute2.
Is it possible to enforce such a rule?
Is it possible to make a value impossible to change after the insert ?
Disallowing attribute1 from being larger than attribute2 can be done with a check constraint:
ALTER TABLE mytable
ADD CONSTRAINT attribute2_greater_check
CHECK (attribute2 >= attribute1)
Preventing update of attribute2 can be done with a trigger that raises an error:
CREATE OR REPLACE TRIGGER mytable_attribute2_update_tr
BEFORE UPDATE ON mytable
FOR EACH ROW
BEGIN
IF :NEW.attribute2 != :OLD.attribute2
THEN
RAISE_APPLICATION_ERROR(-20101, 'attribute2 cannot be updated');
END IF;
END;
/
One way to do is to use an appropriate CONSTRAINT when creating the table:
CREATE TABLE table_name
(
column1 integer,
column2 integer not null,
CONSTRAINT constraint_name CHECK (column1 <= column2)
);
INSERT INTO table_name VALUES(1,1); //ok
INSERT INTO table_name VALUES(2,1); //gives an error
Such constraints can use any fields in the table at hand, but may not access other tables via a subselect.
EDIT: I just realized you also asked another question ... that has been answered already by #Mureinik.