Please note: this project is inactive since early 2006

A.2 Postgresql specific

Name Description Possible values

MDL_PREFERRED_PYTHON_POSTGRESQL_ADAPTOR
By default, the Postgresql Adaptor Layer uses the first module available among the following ones (in that order): psycopg, pgdb, pypgsql. If you have more than one of these modules installed, and you prefer that a specific one is used, you set this variable to the desired name. 'psycopg', 'pgdb', 'pypgsql'
MDL_POSTGRESQL_SERVER_VERSION
Postgresql servers v7.2 and 7.3 behave differently w.r.t. dropping tables and foreign key constraints. With v7.2 the foreign key constraints are not easily dropped, in fact the Postgresql Adaptor Layer does not generate any code for this ; this is however not a problem since v7.2 implicitly drops the related constraints when dropping a table. On the other hand, version 7.3 does not allow a simple DROP TABLE mytable when constraints are bound to table, but it makes it possible to identify and drop the PK/FK constraints. Hence the Postgresql Adaptor Layer can and will generate drop statements for integrity constraints before dropping a table -the other solution would be: DROP TABLE mytable CASCADE but this is explicitly and intentionally not implemented. Please note: this only affects db-schema (re)generation and model validation (because postgresql v7.3 does not support datatype DATETIME anymore) ; this does not affect the runtime core for the moment being. '7.2' (default), '7.3'

Name	Description	Possible values
`MDL_PREFERRED_PYTHON_POSTGRESQL_ADAPTOR`
	By default, the Postgresql Adaptor Layer uses the first module available among the following ones (in that order): `psycopg`, `pgdb`, `pypgsql`. If you have more than one of these modules installed, and you prefer that a specific one is used, you set this variable to the desired name.	`'psycopg'`, `'pgdb'`, `'pypgsql'`
`MDL_POSTGRESQL_SERVER_VERSION`
	Postgresql servers v7.2 and 7.3 behave differently w.r.t. dropping tables and foreign key constraints. With v7.2 the foreign key constraints are not easily dropped, in fact the Postgresql Adaptor Layer does not generate any code for this ; this is however not a problem since v7.2 implicitly drops the related constraints when dropping a table. On the other hand, version 7.3 does not allow a simple `DROP TABLE mytable` when constraints are bound to table, but it makes it possible to identify and drop the PK/FK constraints. Hence the Postgresql Adaptor Layer can and will generate drop statements for integrity constraints before dropping a table -the other solution would be: `DROP TABLE mytable CASCADE` but this is explicitly and intentionally not implemented. Please note: this only affects db-schema (re)generation and model validation (because postgresql v7.3 does not support datatype `DATETIME` anymore) ; this does not affect the runtime core for the moment being.	`'7.2'` (default), `'7.3'`

Comments are welcome: Sebastien Bigaret / Modeling Home Page
Hosted by: