Hi.

Just a minor fix. The table noit.metric_name_summary should have a 
PRIMARY KEY instead of just a UNIQUE constraint, unless I am missing 
something. It makes maintenance of the table less painful and it is 
generally "a good thing" for a table to have primary key.

Here an sql script I used to fix my existing database:

begin;
alter table prism.saved_graphs_dep drop constraint 
"saved_graphs_dep_sid_fkey";
alter table noit.metric_name_summary drop constraint 
"metric_name_summary_pkey";
alter table noit.metric_name_summary add constraint 
"metric_name_summary_pkey" primary key (sid, metric_name, metric_type);
alter table prism.saved_graphs_dep add constraint 
"saved_graphs_dep_sid_fkey" FOREIGN KEY (sid, metric_name, metric_type) 
REFERENCES noit.metric_name_summary(sid, metric_name, metric_type);
commit;


DIFF follows:

Index: sql/tables/noit.metric_name_summary.sql
===================================================================
--- sql/tables/noit.metric_name_summary.sql     (revision 1365)
+++ sql/tables/noit.metric_name_summary.sql     (working copy)
@@ -36,7 +36,7 @@
  --

  ALTER TABLE ONLY metric_name_summary
-    ADD CONSTRAINT metric_name_summary_pkey UNIQUE (sid, metric_name, 
metric_type);
+    ADD CONSTRAINT metric_name_summary_pkey PRIMARY KEY (sid, 
metric_name, metric_type);




-- 
Michal Táborský
chief systems architect
Netretail Holding, B.V.
http://www.nrholding.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.omniti.com/pipermail/reconnoiter-devel/attachments/20100803/da2b3950/attachment.html