Hidy hole in which to stick "uncontrolled" values

In order to make use of the massive speed increases provided by
intarray indexing, we need to use (you guessed it) integers.  But
uncontrolled record attributes are not necessarily (or even very
often) numbers.  We will store them in a table of unique (per
attribute) values, and use the id from that table in our intarray
indexing.  That id comes from a DECREMENTING serial that starts
at -1 and counts downward.  This avoids collision with the other
set of integers (the id from config.coded_value_map) that we will
use for controlled record attribute values.

Signed-off-by: Mike Rylander <mrylander@gmail.com>

diff --git a/Open-ILS/src/sql/Pg/030.schema.metabib.sql b/Open-ILS/src/sql/Pg/030.schema.metabib.sql
index 83200e2..d2b65d0 100644 (file)
--- a/Open-ILS/src/sql/Pg/030.schema.metabib.sql
+++ b/Open-ILS/src/sql/Pg/030.schema.metabib.sql
@@ -268,6 +268,22 @@ CREATE TRIGGER facet_force_nfc_tgr
        BEFORE UPDATE OR INSERT ON metabib.facet_entry
        FOR EACH ROW EXECUTE PROCEDURE evergreen.facet_force_nfc();
 
+-- DECREMENTING serial starts at -1
+CREATE SEQUENCE metabib.uncontrolled_record_attr_value_id_seq INCREMENT BY -1;
+
+CREATE TABLE metabib.uncontrolled_record_attr_value (
+    id      BIGINT  PRIMARY KEY DEFAULT nextval('metabib.uncontrolled_record_attr_value_id_seq'),
+    attr    INT     NOT NULL REFERENCES config.record_attr_definition (id),
+    value   text    NOT NULL
+);
+CREATE UNIQUE INDEX muv_once_idx ON metabib.uncontrolled_record_attr_value (attr,value);
+
+create table metabib.record_attr_vector_list (
+    source  BIGINT  PRIMARY KEY REFERNECES  biblio.record_entry (id),
+    vlist   INT[]   NOT NULL -- stores id from ccvm AND murav
+);
+CREATE INDEX mrca_vlist_idx ON metabib.record_attr_vector_list USING gin ( vlist gin__int_ops );
+
 CREATE TABLE metabib.record_attr (
        id              BIGINT  PRIMARY KEY REFERENCES biblio.record_entry (id) ON DELETE CASCADE,
        attrs   HSTORE  NOT NULL DEFAULT ''::HSTORE