Table of Contents Previous Next



When DATE appears as the data type of a column in the commands, it is translated to TIMESTAMP(0) at the time the table definition is stored in the data base if the configuration parameter edb_redwood_date is set to true. Thus, a time component will also be stored in the column along with the date. This is consistent with Oracle’s DATE data type.
If edb_redwood_date is set to false the column’s data type in a CREATE TABLE or ALTER TABLE command remains as a native PostgreSQL DATE data type and is stored as such in the database. The PostgreSQL DATE data type stores only the date without a time component in the column.
Regardless of the setting of edb_redwood_date, when DATE appears as a data type in any other context such as the data type of a variable in an SPL declaration section, or the data type of a formal parameter in an SPL procedure or SPL function, or the return type of an SPL function, it is always internally translated to a TIMESTAMP(0) and thus, can handle a time component if present.
See the Database Compatibility for Oracle Developers Reference Guide for more information about date/time data types.
When edb_redwood_raw_names is set to its default value of FALSE, database object names such as table names, column names, trigger names, program names, user names, etc. appear in uppercase letters when viewed from Oracle catalogs (for a complete list of supported catalog views, see the Database Compatibility for Oracle Developers Reference Guide). In addition, quotation marks enclose names that were created with enclosing quotation marks.
When edb_redwood_raw_names is set to TRUE, the database object names are displayed exactly as they are stored in the PostgreSQL system catalogs when viewed from the Oracle catalogs. Thus, names created without enclosing quotation marks appear in lowercase as expected in PostgreSQL. Names created with enclosing quotation marks appear exactly as they were created, but without the quotation marks.
When connected to the database as reduser, the following tables are created.
When viewed from the Oracle catalog, USER_TABLES, with edb_redwood_raw_names set to the default value FALSE, the names appear in uppercase except for the Mixed_Case name, which appears as created and also with enclosing quotation marks.
When viewed with edb_redwood_raw_names set to TRUE, the names appear in lowercase except for the Mixed_Case name, which appears as created, but now without the enclosing quotation marks.
In Oracle, when a string is concatenated with a null variable or null column, the result is the original string; however, in PostgreSQL concatenation of a string with a null variable or null column gives a null result. If the edb_redwood_strings parameter is set to true, the aforementioned concatenation operation results in the original string as done by Oracle. If edb_redwood_strings is set to false, the native PostgreSQL behavior is maintained.
The sample application introduced in the next section contains a table of employees. This table has a column named comm that is null for most employees. The following query is run with edb_redwood_string set to false. The concatenation of a null column with non-empty strings produces a final result of null, so only employees that have a commission appear in the query result. The output line for all other employees is null.
The following is the same query executed when edb_redwood_strings is set to TRUE. Here, the value of a null column is treated as an empty string. The concatenation of an empty string with a non-empty string produces the non-empty string. This result is consistent with the results produced by Oracle for the same query.
In Oracle, when a runtime error occurs in a SQL command, all the updates on the database caused by that single command are rolled back. This is called statement level transaction isolation. For example, if a single UPDATE command successfully updates five rows, but an attempt to update a sixth row results in an exception, the updates to all six rows made by this UPDATE command are rolled back. The effects of prior SQL commands that have not yet been committed or rolled back are pending until a COMMIT or ROLLBACK command is executed.
In PostgreSQL, if an exception occurs while executing a SQL command, all the updates on the database since the start of the transaction are rolled back. In addition, the transaction is left in an aborted state and either a COMMIT or ROLLBACK command must be issued before another transaction can be started.
If edb_stmt_level_tx is set to TRUE, then an exception will not automatically roll back prior uncommitted database updates, emulating the Oracle behavior. If edb_stmt_level_tx is set to FALSE, then an exception will roll back uncommitted database updates.
Note: Use edb_stmt_level_tx set to TRUE only when absolutely necessary, as this may cause a negative performance impact.
The following example run in PSQL shows that when edb_stmt_level_tx is FALSE, the abort of the second INSERT command also rolls back the first INSERT command. Note that in PSQL, the command \set AUTOCOMMIT off must be issued, otherwise every statement commits automatically defeating the purpose of this demonstration of the effect of edb_stmt_level_tx.
In the following example, with edb_stmt_level_tx set to TRUE, the first INSERT command has not been rolled back after the error on the second INSERT command. At this point, the first INSERT command can either be committed or rolled back.
A ROLLBACK command could have been issued instead of the COMMIT command in which case the insert of employee number 9001 would have been rolled back as well.
Before creating a link to an Oracle server, you must direct Advanced Server to the correct Oracle home directory. Set the LD_LIBRARY_PATH environment variable on Linux (or PATH on Windows) to the lib directory of the Oracle client installation directory.
For Windows only, you can instead set the value of the oracle_home configuration parameter in the postgresql.conf file. The value specified in the oracle_home configuration parameter will override the Windows PATH environment variable.
The LD_LIBRARY_PATH environment variable on Linux (PATH environment variable or oracle_home configuration parameter on Windows) must be set properly each time you start Advanced Server.
For Windows only: To set the oracle_home configuration parameter in the postgresql.conf file, edit the file, adding the following line:
oracle_home = 'lib_directory '
After setting the oracle_home configuration parameter, you must restart the server for the changes to take effect. Restart the server from the Windows Services console.


Table of Contents Previous Next