MINOR: update Postgres doc for docviewer support. FIXES: #6681

README

@@ -1,42 +0,0 @@
-###############################################
-PostgreSQL Module
-###############################################
-
-Maintainer Contact
------------------------------------------------
-Geoff Munn (Nickname: gmunn)
-<geoff (at) silverstripe (dot) com>
-
-Requirements
------------------------------------------------
-- PostgreSQL 8.3.x or greater must be installed
-- PostgreSQL <8.3.0 may work if T-Search is manually installed
-- Known to work on OS X Leopard, Windows Server 2008 R2 and Linux
-
-Documentation
------------------------------------------------
-http://doc.silverstripe.org/doku.php?id=postgres
-
-Installation Instructions
------------------------------------------------
-
-Move the 'postgres' folder to the root level of the project.
-You'll need to create a database with the desired name manually. 
-Run dev/build and you should be set.
-
-Usage Overview
------------------------------------------------
-
-See the documentation link for examples of PostgreSQL-specific functionality.
-
-Known issues:
------------------------------------------------
-
-All column and table names must be double-quoted.  PostgreSQL automatically lower-cases columns, and your queries will fail if you don't.
-
-Ts_vector columns are not automatically detected by the built-in search filters.  
-That means if you're doing a search through the CMS on a ModelAdmin object, it will use LIKE queries which are very slow.  
-If you're writing your own front-end search system, you can specify the columns to use for search purposes, and you get the full benefits of T-Search.
-
-If you are using unsupported modules, there may be instances of MySQL-specific SQL queries which will need to be made database-agnostic where possible.
-

README.md

@@ -0,0 +1,37 @@
+# PostgreSQL Module Module
+
+## Maintainer Contact
+
+ * Sam Minnee (Nickname: sminnee) <sam@silverstripe.com>
+
+## Requirements
+
+* SilverStripe 2.4
+* PostgreSQL 8.3.x or greater must be installed
+* PostgreSQL <8.3.0 may work if T-Search is manually installed
+*  Known to work on OS X Leopard, Windows Server 2008 R2 and Linux
+
+## Documentation
+
+Move the 'postgresql' folder to the root level of the project. You'll need to 
+create a database with the desired name manually. 
+
+Run dev/build and you should be set.
+
+## Usage Overview
+
+See docs/en for more information about configuring the module.
+	
+## Known issues
+
+All column and table names must be double-quoted.  PostgreSQL automatically 
+lower-cases columns, and your queries will fail if you don't.
+
+Ts_vector columns are not automatically detected by the built-in search 
+filters.  That means if you're doing a search through the CMS on a ModelAdmin
+object, it will use LIKE queries which are very slow.  If you're writing your 
+own front-end search system, you can specify the columns to use for search 
+purposes, and you get the full benefits of T-Search.
+
+If you are using unsupported modules, there may be instances of MySQL-specific 
+SQL queries which will need to be made database-agnostic where possible.

docs/README.md

@@ -1,14 +1,20 @@
 # PostgreSQL Database Module
 
-SilverStripe now has tentative support for PostgreSQL ('Postgres') which is available though this module
+SilverStripe now has tentative support for PostgreSQL ('Postgres').
 
 ## Requirements
 
-SilverStripe 2.4.0 or greater. (PostgreSQL support is NOT available in 2.3.)
+SilverStripe 2.4.0 or greater. (PostgreSQL support is NOT available 
+in 2.3.).
 
-SilverStripe supports Postgres versions 8.3.x, 8.4.x and onwards. Postgres 8.3.0 launched in February 2008, so SilverStripe has a fairly modern but not bleeding edge Postgres version requirement.
+SilverStripe supports Postgres versions 8.3.x, 8.4.x and onwards. 
+Postgres 8.3.0 launched in February 2008, so SilverStripe has a fairly 
+modern but not bleeding edge Postgres version requirement.
 
-Support for 8.2.x is theoretically possible if you're willing to manually install T-search. 8.2.x has not been tested either, so there may be other compatibility issues. The EnterpriseDB versions of Postgres also work, if you'd prefer a tuned version.
+Support for 8.2.x is theoretically possible if you're willing to manually 
+install T-search. 8.2.x has not been tested either, so there may be other 
+compatibility issues. The EnterpriseDB versions of Postgres also work, if 
+you'd prefer a tuned version.
 
 ## Installation
 
@@ -16,21 +22,31 @@ You have three options to install PostgreSQL support with SilverStripe.
 
 ### Option 1 - Installer
 
-The first option is to use the installer. However, this is currently only supported since SilverStripe 2.4.0 beta2 (or using the daily builds).
+The first option is to use the installer. However, this is currently only 
+supported since SilverStripe 2.4.0 beta2 (or using the daily builds).
 
-1. Set up SilverStripe somewhere where you can start the installer - you should only see one database “MySQL” to install with
+1. Set up SilverStripe somewhere where you can start the installer - you 
-2. Download a copy of the “postgresql” module from here: http://silverstripe.org/postgresql-module
+should only see one database “MySQL” to install with.
-3. Extract the archive you downloaded. Rename the directory from “postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe directory you just set up
+2. Download a copy of the “postgresql” module from here: 
-4. Open the installer once again, and a new option “PostgreSQL” should appear. You can now proceed through the installation without having to change any code.
+http://silverstripe.org/postgresql-module
+3. Extract the archive you downloaded. Rename the directory from 
+“postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe 
+directory you just set up
+4. Open the installer once again, and a new option “PostgreSQL” should appear. 
+You can now proceed through the installation without having to change any code.
 
 ### Option 2 - Manual
 
-The second option is to setup PostgreSQL support manually. This can be achieved by following these instructions:
+The second option is to setup PostgreSQL support manually. This can be achieved 
+by following these instructions:
 
 1. Set up a fresh working copy of SilverStripe
 2. Download a copy of the “postgresql” module from here: http://silverstripe.org/postgresql-module
-3. Extract the archive you downloaded. Rename the directory from “postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe directory you just set up
+3. Extract the archive you downloaded. Rename the directory from 
-4. Open up your mysite/_config.php file and add (or update) the $databaseConfig array like so:
+“postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe 
+directory you just set up.
+4. Open up your mysite/_config.php file and add (or update) the $databaseConfig 
+array like so:
 
 > $databaseConfig = array(
 >	'type' => 'PostgreSQLDatabase',
@@ -40,27 +56,35 @@ The second option is to setup PostgreSQL support manually. This can be achieved
 >	'database' => 'SS_mysite'
 > );
 
-Finally, visit dev/build so that SilverStripe can build the database schema and default records.
+Finally, visit dev/build so that SilverStripe can build the database schema and 
+default records.
 
 ### Option 3 - Environment file
 
-Finally, the third option is to change your environment to point to PostgreSQLDatabase as a database class. Do this if you're currently using an _ss_environment.php file.
+Finally, the third option is to change your environment to point to 
+PostgreSQLDatabase as a database class. Do this if you're currently using an
+ _ss_environment.php file.
 
 1. Download a copy of the “postgresql” module from here: http://silverstripe.org/postgresql-module
-2. Extract the archive you downloaded. Rename the directory from “postgresql-trunk-rxxxx” to “postgresql” and copy it into your SS directory
+2. Extract the archive you downloaded. Rename the directory from 
+postgresql-trunk-rxxxx” to “postgresql” and copy it into your SS directory
 3. Add the following to your existing _ss_environment.php file:
 
 > define('SS_DATABASE_CLASS', 'PostgreSQLDatabase');
 
 Last steps:
 
-1. Ensure your SS_DATABASE_USERNAME and SS_DATABASE_PASSWORD defines in _ss_environment.php are correct to the PostgreSQL server
+1. Ensure your SS_DATABASE_USERNAME and SS_DATABASE_PASSWORD defines in 
-2. Ensure that your mysite/_config.php file has a database name defined, such as “SS_mysite”
+_ss_environment.php are correct to the PostgreSQL server.
-3. Visit dev/build so that SilverStripe can build the database schema and default records
+2. Ensure that your mysite/_config.php file has a database name defined, such 
+as “SS_mysite”.
+3. Visit dev/build so that SilverStripe can build the database schema and 
+default records
 
 ## Features
 
-Here is a quick list of what's different in the Postgres module (a full description follows afterwards):
+Here is a quick list of what's different in the Postgres module (a full 
+description follows afterwards):
 
 * T-Search
 * Extended index support
@@ -70,26 +94,41 @@ Here is a quick list of what's different in the Postgres module (a full descript
 * Tablespaces
 * Index clustering
 
-If you don't know much about databases, or don't want to use any of the advanced features that this module provides, then you don't need to read any further.
+If you don't know much about databases, or don't want to use any of the 
+advanced features that this module provides, then you don't need to read 
+any further.
 
-The use of any of these features, especially the advanced options, implies that you have some level of comfort in administrating a Postgres database.
+The use of any of these features, especially the advanced options, implies 
+that you have some level of comfort in administrating a Postgres database.
 
 ### T-Search
 
-T-Search support is provided via both GiST and GIN. You can cluster and search columns with combinations of these methods. It is up to you to decide which is most appropriate for your data.
+T-Search support is provided via both GiST and GIN. You can cluster and 
+search columns with combinations of these methods. It is up to you to 
+decide which is most appropriate for your data.
 
-The dev/build process automatically creates a special column on each table, and a trigger is automatically set up to update this column whenever the targeted columns are changed. T-Search uses this column to return matches for search criteria.
+The dev/build process automatically creates a special column on each table, 
+and a trigger is automatically set up to update this column whenever the 
+targeted columns are changed. T-Search uses this column to return matches 
+for search criteria.
 
-Please see tutorial 4 for information how to enable fulltext search and the necessary controller hooks.
+Please see tutorial 4 for information how to enable fulltext search and the 
+necessary controller hooks.
 
 ### Extended index support
 
-Indexes have been extended to include support for more options. These new options include:
+Indexes have been extended to include support for more options. These new 
+options include:
 
-* The ability to specify index methods (btree/hash/). Btree is probably fine nearly all indexes, and it is the default. 'Unique' is also supported.
+* The ability to specify index methods (btree/hash/). Btree is probably 
-* Partial indexes. This is especially handy for creating an index while ignoring nulls or default data.
+fine nearly all indexes, and it is the default. 'Unique' is also supported.
-* Multiple column indexing. If your WHERE clauses always use the same columns, then you can create one index covering all of these at once.
+* Partial indexes. This is especially handy for creating an index while i
-* Fill factor. If your table content is static, then you can reduce the physical disk space your index uses. Also, if you use clustering, giving the fillfactor a low number may help performance for updates.
+gnoring nulls or default data.
+* Multiple column indexing. If your WHERE clauses always use the same 
+columns, then you can create one index covering all of these at once.
+* Fill factor. If your table content is static, then you can reduce the 
+physical disk space your index uses. Also, if you use clustering, giving the 
+fillfactor a low number may help performance for updates.
 
 Examples:
 
@@ -113,7 +152,8 @@ Examples:
 
 ### Array data types
 
-Nearly all data types in SilverStripe can now be expressed as an array. For example, you can specify an int as this:
+Nearly all data types in SilverStripe can now be expressed as an array. For 
+example, you can specify an int as this:
 
 > $db = array (
 >     'Quantity'=>'Int[]'
@@ -123,26 +163,34 @@ You would populate this like so:
 
 > $item->Quantity='Array[1,2,3...]';
 
-It also takes object literals if you're more familiar with that or it suits your purpose better, like this:
+It also takes object literals if you're more familiar with that or it suits 
+your purpose better, like this:
 
 > $item->Quantity='{1,2,3}';
 
-Using arrays as data types means that you can avoid join tables. This is not recommended if the SilverStripe ORM would expect a has_one or has_many etc under normal circumstances, but it could be useful in the case where you have a very large join table. You can also index these arrays with GIN indexes.
+Using arrays as data types means that you can avoid join tables. This is not 
+recommended if the SilverStripe ORM would expect a has_one or has_many etc under 
+normal circumstances, but it could be useful in the case where you have a very 
+large join table. You can also index these arrays with GIN indexes.
 
 Please consult the official Postgres documentation for more information.
 
 ### Transactions
 
-Transactions are supported at the database connection level. The relevant functions are:
+Transactions are supported at the database connection level. The relevant 
+functions are:
 
 * DB::getConn()→startTransaction($transaction_mode, $session_characteristics)
 * DB::getConn()→transactionSavepoint($name)
 * DB::getConn()→transactionRollback($savepoint)
 * DB::getConn()→endTransaction();
 
-You can create a savepoint by passing a name to the function, and then rollback either all of the uncommited transactions, or if you pass a savepoint name, jump back to the point you'd prefer.
+You can create a savepoint by passing a name to the function, and then rollback 
+either all of the uncommited transactions, or if you pass a savepoint name, 
+jump back to the point you'd prefer.
 
-$transaction_mode and $session_characteristic take the full range of isolation levels supported by Postgres.
+$transaction_mode and $session_characteristic take the full range of isolation 
+levels supported by Postgres.
 
 Please consult the official Postgres documentation for more information.
 
@@ -150,7 +198,9 @@ Please consult the official Postgres documentation for more information.
 
 **This is an experimental feature.**
 
-If you have a very large table, you can split it into many child tables. The advantages of this depend on your particular situation. Generally speaking, if your table is very large, queries should be faster.
+If you have a very large table, you can split it into many child tables. The 
+advantages of this depend on your particular situation. Generally speaking, 
+if your table is very large, queries should be faster.
 
 You can create a partitioned table like this:
 
@@ -163,7 +213,8 @@ You can create a partitioned table like this:
 
 'NEW.' is a required part of the configuration string.
 
-Partitioning should be set up right from the beginning. Partitioning a table which already has data may have unpredictable results.
+Partitioning should be set up right from the beginning. Partitioning a table 
+which already has data may have unpredictable results.
 
 Please consult the official Postgres documentation for more information.
 
@@ -171,15 +222,21 @@ Please consult the official Postgres documentation for more information.
 
 **This is an experimental feature.**
 
-Tablespaces are good for moving the physical files to a faster device (or slower and less used if that's a better option). You can set up a tablespace like this:
+Tablespaces are good for moving the physical files to a faster device (or slower 
+and less used if that's a better option). You can set up a tablespace like this:
 
 > public static $database_extensions = array(
 >    'tablespace'=>Array('name'=>'fastspace', 'location'=>'/faster_location'),
 > );
 
-The '/faster_location' path must be owned by the postgres user. If you try to delete a tablespace via the 'drop tablespace' command, then this directory must be empty.
+The '/faster_location' path must be owned by the postgres user. If you try to 
+delete a tablespace via the 'drop tablespace' command, then this directory must
+be empty.
 
-Changing the location of the tablespace through the SilverStripe $database_extensions array will cause the dev/build process to attempt to delete the old location. An error message will be displayed if this location is not empty.
+Changing the location of the tablespace through the SilverStripe 
+$database_extensions array will cause the dev/build process to attempt to delete 
+the old location. An error message will be displayed if this location is not 
+empty.
 
 Please consult the official Postgres documentation for more information.
 
@@ -187,32 +244,49 @@ Please consult the official Postgres documentation for more information.
 
 **This is an experimental feature.**
 
-Index clustering allows you to reorganise the way rows are ordered inside a table according to an index specification. This can be a very intensive disk operation. You specify an index cluster like this:
+Index clustering allows you to reorganise the way rows are ordered inside a 
+table according to an index specification. This can be a very intensive disk 
+operation. You specify an index cluster like this:
 
 > public static $database_extensions = array(
 >    'cluster'=>'index_name'
 > );
 
-Clustering is only applied on a table on the second instance of a dev/build command being run on it (running a cluster command on an empty table is pointless).
+Clustering is only applied on a table on the second instance of a dev/build 
+command being run on it (running a cluster command on an empty table is 
+pointless).
 
-Clustering needs to be reapplied on a regular basis if you're updating this table. You can also decrease the fillfactor on that index as well for potential performance gains.
+Clustering needs to be reapplied on a regular basis if you're updating this 
+table. You can also decrease the fillfactor on that index as well for 
+potential performance gains.
 
-As an alternative, clustering isn't necessary if you rebuild a table with an ORDER BY clause, where the ORDER BY column is the same as what you'd be clustering it by. The dev/build process does not do table rebuilds, so this is something you'd have to do yourself.
+As an alternative, clustering isn't necessary if you rebuild a table with 
+an ORDER BY clause, where the ORDER BY column is the same as what you'd be 
+clustering it by. The dev/build process does not do table rebuilds, so this 
+is something you'd have to do yourself.
 
 Please consult the official Postgres documentation for more information.
 
 **A note about these advanced features**
 
-The advanced features are here as an experimental offering. They have not been fully tested and their functionality and purpose may change in the future. They are primarily here to offer the ability to handle very large datasets.
+The advanced features are here as an experimental offering. They have not 
+been fully tested and their functionality and purpose may change in the 
+future. They are primarily here to offer the ability to handle very large 
+datasets.
 
-They are also features which require the user to be very familiar with both Postgres and how their data works. If you can't predict how your database will be populated, then most of these features will be of little use.
+They are also features which require the user to be very familiar with both 
+Postgres and how their data works. If you can't predict how your database 
+will be populated, then most of these features will be of little use.
 
 ## User contributed information
 
 **Provided by dompie**
 
-If you want to install this on a more secure postgresql server, go to PostgreSQLDatabase.php and set "public static $check_database_exists = false;"
+If you want to install this on a more secure postgresql server, go to 
-Moreover you have to replace in PostgreSQLDatabaseConfigurationHelper.php occourences of
+PostgreSQLDatabase.php and set "public static $check_database_exists = false;"
+
+Moreover you have to replace in PostgreSQLDatabaseConfigurationHelper.php 
+occurrences of
 
 > $connstring = "host=$server port=5432 dbname=postgres {$userPart}{$passwordPart}";
 
@@ -222,19 +296,26 @@ with
 > $connstring = "host=$server port=5432 dbname=$dbname {$userPart}{$passwordPart}";
 
 
-Otherwise this extension will try to connect to "postgres" Database to check DB connection, no matter what you entered in the "Database Name" field during installation.
+Otherwise this extension will try to connect to "postgres" Database to check DB 
+connection, no matter what you entered in the "Database Name" field during 
+installation.
 
 Make sure you have set the "search_path" correct for your database user. 
 
 ## Known Issues
 
-All column and table names must be double-quoted.  PostgreSQL automatically lower-cases columns, and your queries will fail if you don't.
+All column and table names must be double-quoted.  PostgreSQL automatically 
+lower-cases columns, and your queries will fail if you don't.
 
 Ts_vector columns are not automatically detected by the built-in search filters.  
-That means if you're doing a search through the CMS on a ModelAdmin object, it will use LIKE queries which are very slow.  
+That means if you're doing a search through the CMS on a ModelAdmin object, it 
-If you're writing your own front-end search system, you can specify the columns to use for search purposes, and you get the full benefits of T-Search.
+will use LIKE queries which are very slow.  
 
-If you are using unsupported modules, there may be instances of MySQL-specific SQL queries which will need to be made database-agnostic where possible.
+If you're writing your own front-end search system, you can specify the columns 
+to use for search purposes, and you get the full benefits of T-Search.
+
+If you are using unsupported modules, there may be instances of MySQL-specific 
+SQL queries which will need to be made database-agnostic where possible.
 
 
 

docs/en/README.md

@@ -0,0 +1,321 @@
+# PostgreSQL Database Module
+
+SilverStripe now has tentative support for PostgreSQL ('Postgres').
+
+## Requirements
+
+SilverStripe 2.4.0 or greater. (PostgreSQL support is NOT available 
+in 2.3.).
+
+SilverStripe supports Postgres versions 8.3.x, 8.4.x and onwards. 
+Postgres 8.3.0 launched in February 2008, so SilverStripe has a fairly 
+modern but not bleeding edge Postgres version requirement.
+
+Support for 8.2.x is theoretically possible if you're willing to manually 
+install T-search. 8.2.x has not been tested either, so there may be other 
+compatibility issues. The EnterpriseDB versions of Postgres also work, if 
+you'd prefer a tuned version.
+
+## Installation
+
+You have three options to install PostgreSQL support with SilverStripe. 
+
+### Option 1 - Installer
+
+The first option is to use the installer. However, this is currently only 
+supported since SilverStripe 2.4.0 beta2 (or using the daily builds).
+
+1. Set up SilverStripe somewhere where you can start the installer - you 
+should only see one database “MySQL” to install with.
+2. Download a copy of the “postgresql” module from here: 
+http://silverstripe.org/postgresql-module
+3. Extract the archive you downloaded. Rename the directory from 
+“postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe 
+directory you just set up
+4. Open the installer once again, and a new option “PostgreSQL” should appear. 
+You can now proceed through the installation without having to change any code.
+
+### Option 2 - Manual
+
+The second option is to setup PostgreSQL support manually. This can be achieved 
+by following these instructions:
+
+1. Set up a fresh working copy of SilverStripe
+2. Download a copy of the “postgresql” module from here: http://silverstripe.org/postgresql-module
+3. Extract the archive you downloaded. Rename the directory from 
+“postgresql-trunk-rxxxx” to “postgresql” and copy it into the SilverStripe 
+directory you just set up.
+4. Open up your mysite/_config.php file and add (or update) the $databaseConfig 
+array like so:
+
+> $databaseConfig = array(
+>	'type' => 'PostgreSQLDatabase',
+>	'server' => '[server address e.g. localhost]',
+>	'username' => 'postgres',
+>	'password' => 'mypassword',
+>	'database' => 'SS_mysite'
+> );
+
+Finally, visit dev/build so that SilverStripe can build the database schema and 
+default records.
+
+### Option 3 - Environment file
+
+Finally, the third option is to change your environment to point to 
+PostgreSQLDatabase as a database class. Do this if you're currently using an
+ _ss_environment.php file.
+
+1. Download a copy of the “postgresql” module from here: http://silverstripe.org/postgresql-module
+2. Extract the archive you downloaded. Rename the directory from 
+postgresql-trunk-rxxxx” to “postgresql” and copy it into your SS directory
+3. Add the following to your existing _ss_environment.php file:
+
+> define('SS_DATABASE_CLASS', 'PostgreSQLDatabase');
+
+Last steps:
+
+1. Ensure your SS_DATABASE_USERNAME and SS_DATABASE_PASSWORD defines in 
+_ss_environment.php are correct to the PostgreSQL server.
+2. Ensure that your mysite/_config.php file has a database name defined, such 
+as “SS_mysite”.
+3. Visit dev/build so that SilverStripe can build the database schema and 
+default records
+
+## Features
+
+Here is a quick list of what's different in the Postgres module (a full 
+description follows afterwards):
+
+* T-Search
+* Extended index support
+* Array data types
+* Transactions
+* Table partitioning
+* Tablespaces
+* Index clustering
+
+If you don't know much about databases, or don't want to use any of the 
+advanced features that this module provides, then you don't need to read 
+any further.
+
+The use of any of these features, especially the advanced options, implies 
+that you have some level of comfort in administrating a Postgres database.
+
+### T-Search
+
+T-Search support is provided via both GiST and GIN. You can cluster and 
+search columns with combinations of these methods. It is up to you to 
+decide which is most appropriate for your data.
+
+The dev/build process automatically creates a special column on each table, 
+and a trigger is automatically set up to update this column whenever the 
+targeted columns are changed. T-Search uses this column to return matches 
+for search criteria.
+
+Please see tutorial 4 for information how to enable fulltext search and the 
+necessary controller hooks.
+
+### Extended index support
+
+Indexes have been extended to include support for more options. These new 
+options include:
+
+* The ability to specify index methods (btree/hash/). Btree is probably 
+fine nearly all indexes, and it is the default. 'Unique' is also supported.
+* Partial indexes. This is especially handy for creating an index while i
+gnoring nulls or default data.
+* Multiple column indexing. If your WHERE clauses always use the same 
+columns, then you can create one index covering all of these at once.
+* Fill factor. If your table content is static, then you can reduce the 
+physical disk space your index uses. Also, if you use clustering, giving the 
+fillfactor a low number may help performance for updates.
+
+Examples:
+
+**Hash index**:
+
+> public static $indexes = array(
+>    'Address'=>Array('type'=>'hash', 'name'=>'Address'),
+> );
+
+**Where clause**:
+
+> public static $indexes = array(
+>    'Address'=>Array('type'=>'unique', 'name'=>'Address', 'where'=>"\"Address\" IS NOT NULL"),
+> );
+
+**Fill factor**:
+
+> public static $indexes = array(
+>    'Address'=>Array('type'=>'unique', 'name'=>'Address', 'fillfactor'=>'50'),
+> );
+
+### Array data types
+
+Nearly all data types in SilverStripe can now be expressed as an array. For 
+example, you can specify an int as this:
+
+> $db = array (
+>     'Quantity'=>'Int[]'
+> )
+
+You would populate this like so:
+
+> $item->Quantity='Array[1,2,3...]';
+
+It also takes object literals if you're more familiar with that or it suits 
+your purpose better, like this:
+
+> $item->Quantity='{1,2,3}';
+
+Using arrays as data types means that you can avoid join tables. This is not 
+recommended if the SilverStripe ORM would expect a has_one or has_many etc under 
+normal circumstances, but it could be useful in the case where you have a very 
+large join table. You can also index these arrays with GIN indexes.
+
+Please consult the official Postgres documentation for more information.
+
+### Transactions
+
+Transactions are supported at the database connection level. The relevant 
+functions are:
+
+* DB::getConn()→startTransaction($transaction_mode, $session_characteristics)
+* DB::getConn()→transactionSavepoint($name)
+* DB::getConn()→transactionRollback($savepoint)
+* DB::getConn()→endTransaction();
+
+You can create a savepoint by passing a name to the function, and then rollback 
+either all of the uncommited transactions, or if you pass a savepoint name, 
+jump back to the point you'd prefer.
+
+$transaction_mode and $session_characteristic take the full range of isolation 
+levels supported by Postgres.
+
+Please consult the official Postgres documentation for more information.
+
+### Table Partitioning
+
+**This is an experimental feature.**
+
+If you have a very large table, you can split it into many child tables. The 
+advantages of this depend on your particular situation. Generally speaking, 
+if your table is very large, queries should be faster.
+
+You can create a partitioned table like this:
+
+> public static $database_extensions = array(
+>    'partitions'=>array(
+>         'child_table_1'=>'NEW."ID">0 AND NEW."ID"<=100',
+>         'child_table_2'=>'NEW."ID">100 AND NEW."ID"<=200'
+>    )
+> );
+
+'NEW.' is a required part of the configuration string.
+
+Partitioning should be set up right from the beginning. Partitioning a table 
+which already has data may have unpredictable results.
+
+Please consult the official Postgres documentation for more information.
+
+### Tablespaces
+
+**This is an experimental feature.**
+
+Tablespaces are good for moving the physical files to a faster device (or slower 
+and less used if that's a better option). You can set up a tablespace like this:
+
+> public static $database_extensions = array(
+>    'tablespace'=>Array('name'=>'fastspace', 'location'=>'/faster_location'),
+> );
+
+The '/faster_location' path must be owned by the postgres user. If you try to 
+delete a tablespace via the 'drop tablespace' command, then this directory must
+be empty.
+
+Changing the location of the tablespace through the SilverStripe 
+$database_extensions array will cause the dev/build process to attempt to delete 
+the old location. An error message will be displayed if this location is not 
+empty.
+
+Please consult the official Postgres documentation for more information.
+
+### Index Clustering
+
+**This is an experimental feature.**
+
+Index clustering allows you to reorganise the way rows are ordered inside a 
+table according to an index specification. This can be a very intensive disk 
+operation. You specify an index cluster like this:
+
+> public static $database_extensions = array(
+>    'cluster'=>'index_name'
+> );
+
+Clustering is only applied on a table on the second instance of a dev/build 
+command being run on it (running a cluster command on an empty table is 
+pointless).
+
+Clustering needs to be reapplied on a regular basis if you're updating this 
+table. You can also decrease the fillfactor on that index as well for 
+potential performance gains.
+
+As an alternative, clustering isn't necessary if you rebuild a table with 
+an ORDER BY clause, where the ORDER BY column is the same as what you'd be 
+clustering it by. The dev/build process does not do table rebuilds, so this 
+is something you'd have to do yourself.
+
+Please consult the official Postgres documentation for more information.
+
+**A note about these advanced features**
+
+The advanced features are here as an experimental offering. They have not 
+been fully tested and their functionality and purpose may change in the 
+future. They are primarily here to offer the ability to handle very large 
+datasets.
+
+They are also features which require the user to be very familiar with both 
+Postgres and how their data works. If you can't predict how your database 
+will be populated, then most of these features will be of little use.
+
+## User contributed information
+
+**Provided by dompie**
+
+If you want to install this on a more secure postgresql server, go to 
+PostgreSQLDatabase.php and set "public static $check_database_exists = false;"
+
+Moreover you have to replace in PostgreSQLDatabaseConfigurationHelper.php 
+occurrences of
+
+> $connstring = "host=$server port=5432 dbname=postgres {$userPart}{$passwordPart}";
+
+with
+
+> $dbname = $databaseConfig['database']?$databaseConfig['database']: 'postgres';
+> $connstring = "host=$server port=5432 dbname=$dbname {$userPart}{$passwordPart}";
+
+
+Otherwise this extension will try to connect to "postgres" Database to check DB 
+connection, no matter what you entered in the "Database Name" field during 
+installation.
+
+Make sure you have set the "search_path" correct for your database user. 
+
+## Known Issues
+
+All column and table names must be double-quoted.  PostgreSQL automatically 
+lower-cases columns, and your queries will fail if you don't.
+
+Ts_vector columns are not automatically detected by the built-in search filters.  
+That means if you're doing a search through the CMS on a ModelAdmin object, it 
+will use LIKE queries which are very slow.  
+
+If you're writing your own front-end search system, you can specify the columns 
+to use for search purposes, and you get the full benefits of T-Search.
+
+If you are using unsupported modules, there may be instances of MySQL-specific 
+SQL queries which will need to be made database-agnostic where possible.
+
+
+