|
|
|
|
The following limitations apply to PostgreSQL databases accessed via Libgda:
Postgres uses the "Oid" data type to internally store BLOBs, but this type is also used to store other information within the database. Libgda assumes that any column of type "Oid" represents a blob. If this is not the case, then you must cast it to the correct data type within your SQL query (for example as "SELECT oid::varchar FROM...")
Libgda does not try to avoid orphaned BLOBs, to solve the problem of orphaned BLOBs, set up the "lo" extension from PostgreSQL's contrib, and/or use the "vacuumlo" also from the contrib.
Note that in the future the PostgreSQL's provider will have an option to ensure that there are no orphaned BLOBs itself.
BLOB manipulations can only occur within a transaction, so you should start a transaction before any operation on BLOBs, otherwise Libgda will automatically start one
The gda_connection_statement_execute_non_select()'s last_insert_row parameter will return a new GdaSet object only if the table has OIDs (to ensure this, the "WITH OIDS" option should be added at the end of a CREATE TABLE query).
If PostgreSQL was not compiled with the --enable-thread-safety flag,
then the database provider will only allow
connections to be opened from the thread which initializes Libgda. Otherwise there is no limitation.
It is not possible to execute a SELECT statement with invalid parameters and with the GDA_STATEMENT_MODEL_ALLOW_NOPARAM flag if the GDA_STATEMENT_MODEL_CURSOR_FORWARD flag is also specified
Timezone information associated with time and timestamp data types is not stored by PostgreSQL, so when executing statements all the variables containing a time or timestamp information are converted to GMT (timezone 0) before the execution happens. The consequence is that for example if a variable holds the "11:23:55+2" time (11 hours, 23 minutes and 55 seconds, at GMT + 2), then the actual time stored in the database will be "09:23:55", the same time but GMT.