Index: openacs-4/packages/acs-content-repository/sql/postgresql/content-type.sql
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-content-repository/sql/postgresql/content-type.sql,v
diff -u -r1.57.2.3 -r1.57.2.4
--- openacs-4/packages/acs-content-repository/sql/postgresql/content-type.sql	10 Feb 2016 09:14:20 -0000	1.57.2.3
+++ openacs-4/packages/acs-content-repository/sql/postgresql/content-type.sql	21 Apr 2017 14:53:07 -0000	1.57.2.4
@@ -454,7 +454,7 @@
                                         drop_attribute__attribute_name);
 
   -- FIXME: postgresql does not support drop column.
-  -- Drop the column if neccessary
+  -- Drop the column if necessary
   if drop_attribute__drop_column then
       execute 'alter table ' || v_table || ' drop column ' ||
         drop_attribute__attribute_name || ' cascade';
@@ -698,8 +698,8 @@
 -- into the input view when a new content revision is added.  Pg locks the 
 -- underlying table when the rule is dropped, so the dropping and recreating
 -- of the new content revisons seems like it would be reliable, but the 
--- possiblity of a race condition exists for either the initial creation
--- of dropping of a type.  I'm not sure if the possiblity of a race condition
+-- possibility of a race condition exists for either the initial creation
+-- of dropping of a type.  I'm not sure if the possibility of a race condition
 -- acually exists in practice.  The thing to do here might be to just create 
 -- a function that dynamically builds the insert strings and does the 
 -- each time an insert is done on the content_type view.  Trade-off being