Document newly added MATERIALIZE VIEWS for new sources.

Now it's possible to use this clause with a PostgreSQL or an MS SQL database
source.

Fixes #817.

Author: dimitri

docs/ref/mssql.rst

@@ -31,7 +31,7 @@ MS SQL Database Migration Options: WITH
 ---------------------------------------
 
 When loading from a `MS SQL` database, the same options as when loading a
-`MySQL` database are supported. Please refer to the MySQL section. The
+`MS SQL` database are supported. Please refer to the MS SQL section. The
 following options are added:
 
   - *create schemas*
@@ -53,7 +53,39 @@ CAST
 The cast clause allows to specify custom casting rules, either to overload
 the default casting rules or to amend them with special cases.
 
-Please refer to the MySQL CAST clause for details.
+Please refer to the MS SQL CAST clause for details.
+
+MS SQL Views Support
+--------------------
+
+MS SQL views support allows pgloader to migrate view as if they were base
+tables. This feature then allows for on-the-fly transformation from MS SQL
+to PostgreSQL, as the view definition is used rather than the base data.
+
+MATERIALIZE VIEWS
+^^^^^^^^^^^^^^^^^
+
+This clause allows you to implement custom data processing at the data
+source by providing a *view definition* against which pgloader will query
+the data. It's not possible to just allow for plain `SQL` because we want to
+know a lot about the exact data types of each column involved in the query
+output.
+
+This clause expect a comma separated list of view definitions, each one
+being either the name of an existing view in your database or the following
+expression::
+
+  *name* `AS` `$$` *sql query* `$$`
+
+The *name* and the *sql query* will be used in a `CREATE VIEW` statement at
+the beginning of the data loading, and the resulting view will then be
+dropped at the end of the data loading.
+
+MATERIALIZE ALL VIEWS
+^^^^^^^^^^^^^^^^^^^^^
+
+Same behaviour as *MATERIALIZE VIEWS* using the dynamic list of views as
+returned by MS SQL rather than asking the user to specify the list.
 
 MS SQL Partial Migration
 ------------------------
@@ -96,7 +128,7 @@ schema 'public' in the target database with this command::
 ALTER TABLE NAMES MATCHING ... IN SCHEMA '...'
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-See the MySQL explanation for this clause above. It works the same in the
+See the MS SQL explanation for this clause above. It works the same in the
 context of migrating from MS SQL, only with the added option to specify the
 name of the schema where to find the definition of the target tables.
 

docs/ref/pgsql.rst

@@ -283,6 +283,38 @@ The supported casting options are:
 
       column enumerate.foo using empty-string-to-null
 
+PostgreSQL Views Support
+------------------------
+
+PostgreSQL views support allows pgloader to migrate view as if they were
+base tables. This feature then allows for on-the-fly transformation of the
+source schema, as the view definition is used rather than the base data.
+
+MATERIALIZE VIEWS
+^^^^^^^^^^^^^^^^^
+
+This clause allows you to implement custom data processing at the data
+source by providing a *view definition* against which pgloader will query
+the data. It's not possible to just allow for plain `SQL` because we want to
+know a lot about the exact data types of each column involved in the query
+output.
+
+This clause expect a comma separated list of view definitions, each one
+being either the name of an existing view in your database or the following
+expression::
+
+  *name* `AS` `$$` *sql query* `$$`
+
+The *name* and the *sql query* will be used in a `CREATE VIEW` statement at
+the beginning of the data loading, and the resulting view will then be
+dropped at the end of the data loading.
+
+MATERIALIZE ALL VIEWS
+^^^^^^^^^^^^^^^^^^^^^
+
+Same behaviour as *MATERIALIZE VIEWS* using the dynamic list of views as
+returned by PostgreSQL rather than asking the user to specify the list.
+
 PostgreSQL Partial Migration
 ----------------------------