mirrors/pgloader
1
0
Fork 0
mirror of https://github.com/dimitri/pgloader.git synced 2026-05-04 18:36:12 +02:00
Code Issues Projects Releases Wiki Activity

Document newly added MATERIALIZE VIEWS for new sources.

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

Fixes #817.
This commit is contained in:
Dimitri Fontaine 2018-12-19 10:51:04 +01:00
parent c019c16113
commit 2cafa8360c
2 changed files with 67 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
docs/ref/mssql.rst
View File

@ -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.

32
docs/ref/pgsql.rst
View File

@ -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
----------------------------