Added rollout.sh + made all script executable on their own

kmoppel · kmoppel · commit f04794867080 · 2017-09-11T23:21:37.000+03:00
diff --git a/00_create_database.sql b/00_create_database.sql
@@ -15,6 +15,3 @@ In case of multiple environments (enterprize scenario) it is highly recommended
 minimize chances of executing things on the wrong DB - e.g. dev_app1_db, prod_app1_db.
 
 */
-
--- assuming "psql" as execution environment here
-\c pg_features_demo
diff --git a/01_create_role.sql b/01_create_role.sql
@@ -1,8 +1,12 @@
+-- assuming "psql" as execution environment here
+\c pg_features_demo
+
 -- Create a role (a.k.a: user, login, group) that is allowed to log in.
 -- NB! By default roles are allowed to connect to all databases of a cluster. This does not mean that they can automatically access tables though.
 -- But if this is not wanted, per DB connections can be set up with "REVOKE/GRANT CONNECT ON DATABASE"
 
 CREATE ROLE demorole WITH LOGIN;    -- create a normal(unprivileged) user
+                                    -- NB! when seeing ERRORs during re-rollout it's normal here as role are "global" objects
 
 -- Will later be set up to only allow selecting data
 CREATE ROLE demorole_ro WITH LOGIN;
diff --git a/02_create_schema.sql b/02_create_schema.sql
@@ -1,4 +1,5 @@
-RESET ROLE;
+\c pg_features_demo
+
 /*
 Schemas in Postgres are basically "namespaces", allowing tables with same names within one DB, if schema names differ.
 By default there is always one "public" schema pre-created with every database, but for bigger applications it is usually 
diff --git a/02_search_path.sql b/02_search_path.sql
@@ -1,3 +1,5 @@
+\c pg_features_demo
+
 /* 
 
 Important concept tied to schemas is "search_path". Basically it's a priority list of schemas, 
diff --git a/03_make_public_schema_secure.sql b/03_make_public_schema_secure.sql
@@ -1,3 +1,5 @@
+\c pg_features_demo
+
 /*
 
 For sensitive environments it is recommended to avoid creating object in the "public" schema or even better to secure
@@ -17,4 +19,3 @@ GRANT USAGE ON SCHEMA public TO demorole_ro;
 ALTER DEFAULT PRIVILEGES
     IN SCHEMA public
 	GRANT SELECT ON TABLES TO demorole_ro;
-
diff --git a/04_alter_role.sql b/04_alter_role.sql
@@ -1,11 +1,8 @@
+\c pg_features_demo
+
 -- It's possible to set global, or per user or per user/db settings. Most used such settings are search_path and statement_timeout.
 -- Changes are effective with next login.
 
-RESET ROLE;
-
 ALTER ROLE demorole IN DATABASE pg_features_demo SET search_path TO public, banking;
 ALTER ROLE demorole_ro IN DATABASE pg_features_demo SET search_path TO public, banking;
 ALTER ROLE demorole_ro IN DATABASE pg_features_demo SET statement_timeout TO '5s';
-
-SET ROLE TO demorole;
-
diff --git a/05_create_table.sql b/05_create_table.sql
@@ -1,3 +1,5 @@
+\c pg_features_demo
+
 -- assume "application" role
 -- it's a good practice to own all objects by one "application" role, so that changes could be done using the same role, 
 -- not requiring the samewhat dangerous "superuser".
diff --git a/06_create_table_options.sql b/06_create_table_options.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Other ways of creating tables are:
     1) using LIKE to use existing tables as a templates and selecting (or leaving out) some constraints/checks/indexes
diff --git a/07_alter_table.sql b/07_alter_table.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 ALTER TABLE is mostly commonly used to:
     1) add/drop/rename columns
diff --git a/09_data_type_showcase.sql b/09_data_type_showcase.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 CREATE TABLE public.main_datatypes (
     /* serials aka sequences */
     id          bigserial PRIMARY KEY,   -- serial/bigserial corresponds to int4/int8 and will just auto-attach a DEFAULT sequence
diff --git a/10_views.sql b/10_views.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Views allow application layering and can be also used for securing data. They behave the same as tables for GRANT privileges and
 don't normally incur any performance hit when selecting.
diff --git a/15_materialized_views.sql b/15_materialized_views.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 -- Materialized view is a "point in time" copy of the select statement and needs explicit refreshing
 -- In other aspects the mat.view acts like a normal table - one can create indexes on it 
 
diff --git a/20_stored_procedures.sql b/20_stored_procedures.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 PL/pgSQL is a specialized programming language that allows to query data and provides common features like variables, comparisons, 
 branching (if/else), error handling, calling other functions.
diff --git a/25_table_using_sproc.sql b/25_table_using_sproc.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 -- setting a function as default value
 -- dropping the function with "cascade" will also remove the "default" declaration
 CREATE TABLE func_as_def_param(
diff --git a/30_simple_trigger.sql b/30_simple_trigger.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Triggers function similar to other RDBMSs - first you declare a "trigger function" and then the trigger itself on a specific table. Thus 
 one fuction can be used for X tables. Trigger functions are almost like normal PL/pgSQL function but they can only return "trigger" 
diff --git a/32_event_trigger.sql b/32_event_trigger.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 CREATE OR REPLACE FUNCTION rewrite_date_check() RETURNS event_trigger AS
 $$
 BEGIN
diff --git a/40_custom_types.sql b/40_custom_types.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Postgres is a the most extensible general purpose RDBMS out there and one of the most used extensibility feature is creating custom 
 types that can be thought of as "classes" in the object-oriented programming world. Created types can then be used as built-in 
diff --git a/41_enum_types.sql b/41_enum_types.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Special subtype of custom types are ENUMs. Concept is the same as in other programming languages, enabling to assing a nice label
 to some internally stored code value, helping with clarity and also performance for bigger data amounts.
diff --git a/45_domains.sql b/45_domains.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Domains allow extending data types with checks so that you don't have to change multiple single checks when validation requirements change.
 */
diff --git a/50_row_level_security.sql b/50_row_level_security.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Row Level Security (RLS) is quite a new feature (9.5+) and allows having tables where it is guaranteed that all unprivileged users 
 will see only rows that they're allowed to see based on some filter condition. Needs enabling per table.
diff --git a/60_transaction_management.sql b/60_transaction_management.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Transaction management is a complex topic but most importantly one should know that Postgres has 3 different isolation levels:
     
diff --git a/70_basic_analytics.sql b/70_basic_analytics.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Postgres has rich analytics support. Analytics can mean a lot of things but here it means there are functions that in addition to
 normal aggregates (AVG, SUM, etc) can also compare individual rows and row groupings! Thus enabling answering questions like - 
diff --git a/80_advanced_indexing.sql b/80_advanced_indexing.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 
 For good performance it's essential that frequent queries take advantage of indexes.
diff --git a/81_string_processing.sql b/81_string_processing.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 Postgres has excellent text/string processing capabilities, including support for regular expressions.
 Below some of the most useful functions and text handling techniques.
diff --git a/82_arrays.sql b/82_arrays.sql
@@ -1,3 +1,6 @@
+\c pg_features_demo
+SET ROLE TO demorole;
+
 /*
 
 Arrays can be composed from all data types and are first class citizens in Postgres, being used a lot for internal catalogs.
diff --git a/README.md b/README.md
@@ -3,10 +3,12 @@
 Sample object creation and query scripts to illustrate different Postgres object types and data quering possibilities.
 Targeted for beginners.
 
-Rollout with psql:
+### Rollout
+
+For running all the scripts on a local Postgres DB (superuser assumed) use the provided rollout.sh script which consist of:
 
 ```
-ls -1 *.sql | sort -V | xargs cat | psql
+ls *.sql | sort -n | xargs -n 1 psql -f
 ```
 
 All feedback welcome!
diff --git a/rollout.sh b/rollout.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+# Will create a new database "pg_features_demo". NB! Superuser rights are assumed.
+#
+# If not running a local Postgres server use libpq standard environment variables to specify connection string - e.g.:
+# export PGHOST=some.ip.com
+# export PGPORT=5433
+# export PGUSER=myuser
+# export PGDATABASE=postgres
+ls *.sql | sort -n | xargs -n 1 psql -f

Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,5 @@`
	`1`	`+\c pg_features_demo`
	`2`	`+`
`1`	`3`	`/*`
`2`	`4`
`3`	`5`	`Important concept tied to schemas is "search_path". Basically it's a priority list of schemas,`
Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,5 @@`
	`1`	`+\c pg_features_demo`
	`2`	`+`
`1`	`3`	`-- assume "application" role`
`2`	`4`	`-- it's a good practice to own all objects by one "application" role, so that changes could be done using the same role,`
`3`	`5`	`-- not requiring the samewhat dangerous "superuser".`