Go to file
Ingo Schommer cd7b761bed BUG Faulty query escape in tableList()
This caused tables starting with "sql" to be excluded from
the tableList() results, where only "sql_" should be filtered.
An unescaped underscore in ANSI SQL pattern matching stands
for "any single character", the escape needed to be doubled
to account for PHP's own escape expanding.

This broke SQLQueryTest since the test data wasn't reset
between test runs.
2012-12-11 15:09:10 +01:00
code BUG Faulty query escape in tableList() 2012-12-11 15:09:10 +01:00
docs MINOR: update Postgres doc for docviewer support. FIXES: #6681 2012-06-29 17:56:38 +12:00
tests MINOR Added PostgreSQLDatabaseTest with a database specific readonly transaction test (moved here from sapphire/tests/TransactionTest.php 2011-03-14 16:47:44 +13:00
_config.php GiST and Tsvector references removed so DB/build will work 2009-01-09 03:43:28 +00:00
CHANGELOG MINOR: changelog for the 0.9.2 release 2010-11-11 20:50:57 +00:00
composer.json New : Added composer.json 2012-09-22 20:41:59 +05:30
LICENSE MINOR: Documentation update for the 0.9.1 release 2010-06-01 01:31:33 +00:00
README.md Corrected minimum requirements, 3.0 only since at least 6e30463e 2012-10-12 15:19:46 +02:00

PostgreSQL Module Module

Maintainer Contact

Requirements

  • SilverStripe 3.0
  • 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

Installation

  1. Extract the contents so they reside as a postgresql directory inside your SilverStripe project code
  2. Open the installer by browsing to install.php, e.g. http://localhost/silverstripe/install.php
  3. Select PostgreSQL in the database list and enter your database details

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.