Nothing in the above list is likely to be of concern for the vast majority of Composr users who also who would want to use Postgres.
#PSEQUEL ALTERNATIVE CODE#
Laxness modes designed to help ensure amateur Composr developers write or port code without knowing too much about database portability (MySQL is the only database backend that has non-strictness, and in other cases we are just doing some niceties to smooth things over when developers assume MySQL).Extra development mode security checks designed to help ensure amateur Composr developers write secure code.
#PSEQUEL ALTERNATIVE PATCH#
Upgrade code is only tested for MySQL (upgrades for professional sites should be done by a developer, who should be able to patch around any issues in the upgrade code and pass fixes back to mainline Composr).The MySQL optimiser cleanup tool is MySQL only (other database backends are better at doing automatic cleanup).The bundled rootkit_detector addon is hard-coded to MySQL (this is developed for experts and bakes in assumption of mysqli due to running outside of Composr the code can be customised to other backends as required).We only do minimum version check for MySQL (MySQL is the only serious database backend that tends to not support basic stuff until recent versions!).
#PSEQUEL ALTERNATIVE HOW TO#
The database repair cleanup tool is only for MySQL (we use this to help test our upgrade code works perfectly, or to make it easier for 3rd-party developers who don't know how to correctly code to our database meta-system it is not required and SQL structure dump comparison will work as a substitute in most cases).Documentation is written with MySQL in mind, particularly tutorials relating to installation, performance, and maintenance (however experienced system/database administrators will be able to adapt instructions to the systems they use without too much trouble).Commandr-fs feature for listing when tables were last updated is only for MySQL (other database backends tend to not provide last-updated timestamps for tables).Certain esoteric performance optimisations for certain cases of large amounts of data are only for MySQL (the MySQL support is heavily optimised for a wide range of high load scenarios similar Postgres optimisations will be made as client requirements come up).
Inside a commercial relationship whatever extra testing and bug fixing is required will be done under that relationship, and fixes put back into the mainline version of Composr. Different database systems vary in all kinds of surprising and subtle ways. However officially only MySQL is supported outside of a commercial relationship, due to the significant effort testing across new versions of Composr and the database backends involved. This tutorial provides some advice targeted towards PostgreSQL (also known simply as 'Postgres').Ĭomposr has internal 'support' for many different databases backends and is intentionally written with a combination of simple common-denominator SQL and use of an abstraction API.