pgExpress Driver 4.50

Question

1.

What is the pgExpress Driver ?

Answer 1

The pgExpress Driver is a PostgreSQL v7.1+ dbExpress Driver for Codegear Delphi 6+/Codegear Kylix/Codegear C++ Builder 6+.

It can use all PostgreSQL field types, and is compliant to the Codegear specifications of dbExpress drivers.

Please refer to the Changelog of the pgExpress Driver for the changes history.

Answer 2

Please refer to http://community.borland.com/article/0,1410,28688,00.html.

Answer 3

As of the time this is written, the pgExpress Driver was tested and runs properly under Kylix 1/2/ 3, Delphi6/ 7 and Codegear C++ Builder 6. The supported PostgreSQL servers are 7.10 to 7.31. Support for the forthcoming PostgreSQL versions will appear as they get released.

Answer 4

PostgreSQL 7.4 is supposed to introduce a native port for Windows. You can try the free cygwin port, available at the Cygwin package at http://www.cygwin.com. You can also buy a commercially supported Cygwin based port from http://www.dbexperts.net.

Answer 5

Since the VCL/CLX parses the colons (':') as being parameters delimiters, you need to use double colons in SQL syntax. Colons are used to do typecasts as:

/*Instead of 'select typelem::int4 from pg_type;' */
            select typelem::::int4 from pg_type;

You can also use the cast() function, similary:

select cast(typelem as integer) from pg_type;

The pgExpress Suite includes proper escaping functions to work with such queries.

Answer 6

The problem is Delphi's weirdness :-) You should use a code like this:

procedure TForm1.Button1Click(Sender: TObject);
begin
with SQLClientDataSet1 do
  begin
    CommandText := 'select * from pg_type where typname ~~ :type';
    if Active then
    begin
      Params[0].AsString := Edit1.Text;
      Execute;
      Refresh
    end       
    else
    begin
      with Params.CreateParam(ftString, 'type', ptInput) do
      AsString := Edit1.Text;
      Open;
    end;
  end;
end

Obs:

The pg_type table is an internal PostgreSQL catalog table that is avaiable on all PostgreSQL databases, so it's a good table to work as example.

Now explaining it:

Before calling a parametrized query, you must create a TParam for each parameter you set in the CommandText property, and assign them to the TSQLClientDataset.Params property:
```
with Params.CreateParam(ftString, 'type', ptInput) do
                AsString := Edit1.Text;
```
Good values to use as test Paramaters are '%a%' (for matching any type that has an 'a' in its name) or 't%' (for any type that starts with 't'). Remember that '%' is PostgreSQL's wildcard char.
The first time you open the query, everything hould be ok: the parameter is correctly interpreted and the query comes filtered:
```
Open;
```
As quoted from the Delphi's help's [TCustomClientDataSet.Params] entry, we have to set the new Param value and then call Execute at the second time:

“ Warning: The parameters are only applied to the provider when a query or stored procedure is run the first time the client dataset fetches records. To change parameter values and force a query or stored procedure to be rerun with new values, use the Execute method." ”

... what lead us to...
```
Params[0].AsString := Edit1.Text;
                Execute;
```
After calling Execute, we have to refresh (or close/reopen) the TSQLClientDataset so it willl match the new rows retrieved:
```
Refresh;
```

Answer 7

This happens because the Delphi String field has a limited size and psql text fields have arbitrary length. Thus, pgExpress is obligated to allocate the maximum string length, which is 32k. This leads to datasets that are slow and uses more memory then what's needed most times. Unhappily, this is a dbExpress design flaw (or "misfeature"): there is no real support to variable length strings, only for fixed lengthed. Mapping those text fields as (Blob) Memo fields will be more efficient the as strings in terms of memory. If you can do it, however, we advice to change your text fields to varchar or char field types with a smaller field length; they will be more efficient in Delphi due to the more efficient memory allocation. To do this, define the TextAsMemo special param in your configuration (please follow the steps in the pgExpress Driver distribution's documentation):

TextAsMemo = True

Also you might want to define poFetchBlobsOnDemand in your TSQLClientDataset.Options property (or in your TProvider). This will fetch the blob fields only on demand, making the grids scroll much faster and using less memory.

The pgExpress Suite product circunvents this issue automatically for the string fields.

Note

TextAsMemo=True is the default behavior for the pgExpress Driver.

Answer 8

This is not a bug, but a PostgreSQL feature. The '\' is used to escape the SQL strings to allow use of chars like ''' (which is the string delimiter), '\t' (TAB), '\0' (char #0), etc - pretty much like C language or the Format() function, familiar to DelphiKylixC++ Builder/. Without this feature, it wouldn't be possible to uses such chars in SQL queries. Please refer to the link below for more information:

http://www.vitavoom.com/postgresql-docs/sql-syntax.html#SQL-SYNTAX-STRINGS

Answer 9

The problem is caused by a dbExpress VCL/CLX bug. There is an interface called ISQLCursor.isSearchable() making an update query, and that would create a statement that would have a non-existent value, like this:

update test set b = '2002-08-02 18:36:50' where b = '2002-08-02 18:36:52';

Obviously PostgreSQL will not be able to find the b value from the WHERE clause, and a exception message like this will be raised:

Record not found or changed by another user

To solve this, use a primary key/index and the UpdateMode to upWhereKeyOnly mode with keys on fields that are not timestamp/ datetime/etc (do not make the timestamp values indexed). This will keep VCL/CLX from generating a wrong WHERE statement.

If in your database these fields are indexed, removing the pfInWhere option from the TField.ProviderFlags property for that field should be enough. If the actual value in your table that have no fraction or timezone value values, the generated SQL will be able to find that record (because it will use only the indexed fields in the WHERE clause, and the update will suceed.

Another way of solving this issue is by using a view using the date_trunc function, like this:

create view TestView as select a, date_trunc('second', b) as b from test;

and then create a rule to INSERT/UPDATE/DELETE rows, but this method is more complicated.

The pgExpress Suite does not suffer from this problem since it maps the fields to custom types. Just to document, the Delphi 7 Readme.txt file has a similar “Known Issues” note for the DB2 dbExpress driver.

Answer 10

In fact pgExpress *does* support it, but you have to do it the right way (please read the note at the end of the answer):

select oid, * from pg_type;

In your TSQLDataset component, construct your query so that it will retrieve the OID field. If you don't explicitly declare you don't want this field, psql will not return it. An example:
In your TSQLDataset component, for all the TField field definitions, unset all the ProviderFlags = pfInKey, except for the OID field definition; this field has to have the pfInKey ProfiderFlag. This is because it will be our primary key.
You might also want to set for the OID field definition the pfHidden flag. This means it will be used on updates for can't be seen by the client (what makes total sense with OID fields).
Set TSQLDataset.UpdateMode = upWhereKeyOnly . This will make OID field the only one used to generate the WHERE statements.
That's it. An alternative way would be using TSQLDataset.UpdateMode = upWhereAll, and deactivate the pfInWhere flag for all other fields.

Notes:

As of PostgreSQL7.2, the OID field is optional. Certify that the table you want to use for OID updates has that field before trying to use it.
Contrary to what most users think, OID fields are not indexed. This means the updates whose WHERE clause are based on those fields will be slow, since a sequential scan will have to be used. Thus, we don't advice using OID fields for doing the updates, unless you make an explicity index for it (yes, that is perfectly legal). Probably a standard primary key field would be much better for doing the updates.

Answer 11

The pgExpress Driver itself uses very little memory. The problem is the behavior of libpq and TClientDataset: both cache the rows read from the server. Imagine the following situation: you run a query which reads 100.000 records from the server. The libpq library will cache all of them, as strings, in the memory. Additionally, the TClientDataset (remember that TSQLClientDataset and TSimpleDataset also have an internal TClientDataset component, which inherites from TCustomCachedDataset , which caches all rows read) component will be caching every record internally too. This will end up caching the rows twice. For large datatsets, this could mean lots of megabytes of memory used.

To minimize this effect, we have to reduce the memory used by the libpq library, using the BlockRead special param. The libpq library will only cache RowsetSize records, which usually is a small value (like 100). This will reduce the memory spent by libpq and have an enourmous impact on the overall memory usage.

Also, since TClientDataset caches the records in a binary format, they usually spend less memory then their string versions (as stored internally by the libpq library).

Answer 12

To develop using dbExpress can be a bit tricky sometimes, due to the amount of flexibility the technology provides, and to the new paradigm it offers. Hapifully, it's fairly easy to use dbExpress when you know how. We recommend this book for dbExpress development:

Delphi/Kylix Database Development DataCLX for Windows and Linux by Eric Harmon

Get it at:

Publisher's site

Amazon

Answer 13

The problem here is a incompatilibity between the decimal separator of the client system (the Delphi/Kylix/C++ Builder program) and the PostgreSQL server. Usually, the PostgreSQL uses the "C" locale, which uses '.' as decimal separator. In a few cases, the pgExpress Driver won't detect this change automatically: the pgExpress Driver will be expecting '.' as decimal separator, and not ',' as used by some locales (such as most european locales). When the pgExpress Driver tries to convert the server value (ex: '1,0') expecting a '.', an exception is raised by the VCL/CLX.

To circunvent this, you can either:

Use the "C" locale (or any other locale that uses '.' as decimal separator; (an easy way to do it is editing your postgresql.conf file)
... or use the ServerDecimalSeparator special param to switch the decimal separator char to ',' (or '.' depending on your setup).

On PostgreSQL 7.4+, you might update the locale settings on the fly:

update pg_settings set setting='C' where name='lc_numeric';
update pg_settings set setting='C' where name='lc_monetary';

Note

If the pgExpress Driver can't automatically detect the decimal separator on your system, and you want to help us debugging it, please create an empty database and send us host/user/password/database information so that we can connect on your database and test it. No data will be harmed of course.

Answer 14

The libpq library needs Winsock 2 in order to sucessfully connecting to the PostgreSQL server. Please install the Winsock 2 update and everything should work.

Answer 15

The query/function is returning a VARCHAR VARCHAR field without length specifier; that could be up to 4gb in size. Since the VCL/CLX does not support arbitrary length string fields, they must be mapped as Memo fields.

Fixing this situation is easy: just specify a length to those string fields:

select cast(f1, varchar(30)) from mytable;

The same behavior can occur when using functions that return variable length VARCHAR fields:

              select substr(name, 1, 10) from mytable;

To get what you expect from this query, use:

              select cast(substr(name, 1, 10), varchar(10)) from mytable;

Answer 16

This is happening because the VCL/CLX is not being able to find - or is finding more then one - record which you're trying to change. This is not a bug at all; it's instead a lack of configuration parameters. Probably you need to set a primary key in your dataset, and the generated update statement will have a WHERE clause valid for that record. The SQL generated by dbExpress is directly a related to the database primary key and the parameters set on the VCL/CLX database components.

The default TDatasetProvider Provider update setting is upWhereAll; that is rather inneficient since it will use all the fields in the dataset to compose the primary key used in the WHERE clase of the SQL statement - and it probably was not enough since the error message above is being raised. Instead, try to use upWhereKey on the TDatasetProvider and set the appropriate values on the TSQLDataset's field's ProviderFlags property to the dataset's primary key. Please read the documentation of these properties for more details.

To debug this situation and understand the exact communication between the pgExpress Driver and the PostgreSQL server, try attaching a TSQLMonitor into your TSQLCOnnection and inspect the produced log, or instead activating debug logging into the PostgreSQL server and checking it directly. The WHERE clause produced should be reflecting the properties described above.

Answer 17

Depending on the compiler which compiled the libpq, it could be the msvcr80.dll file instead. Try installing the msvcr71.dll library into your system, or using the which comes with the official for Windows distribution.

Answer 18

Please update your Delphi 2007 installation.

Answer 19

Normally this is caused to bad detabase design or to force compatibility with other database systems. PostgreSQL distinguishes between upper and lower cases when the object names are quote, e.g.:

select "typname" from pg_type;
select TYPNAME from pg_type;

That query will suceed while the following ones will not:

select "Typname" from pg_type;
select typname from "PG_TYPE";

Since the VCL/CLX quotes the objects names by default, PostgreSQL will be distinguishing between them.

To avoid that, up to Delphi 7, please use the QuoteObjects (beware that uses an internal pgExpress Driver hack. On later Delphi versions, disable TDatasetProvider.Options poUseQuoteChar flag.

For a better understanding of what is running under the scenes between the pgExpress Driver and the PostgreSQL server, and check the quotes added to statements, please attach a TSQLMonitor into your TSQLConnection component and log the communication between them into a file.

Answer 20

Of course: that's what we are here for. But to allow us to help you better, please include in your email (whenever it applies):

The Delphi/Kylix/Codegear C++ Builder, pgExpress Driver server (PostgreSQL's) and client (pgExpress's) OSs, PostgreSQL and libpq versions you are using.
If you are a registered customer, quote your registered user's name somewhere into the top of the email, such as: "Registered User Name: xxxxxxxxxxxx". Registered users always have priority support.
A small (as bare as possible) project that allows us to reproduce your problem. Try to set it's TSQLConnection.ConnectionName to "PGEConnection" (this is the the default test entry for the pgExpress Driver). If your project has a problem just by loading a table, this could be skipped; otherwise, please do it.
A pg_dump of your data/table with the '-d' option. This option will generate INSERT instead of COPY commands and will be more portable and easier to restore. All tables accessed by your project should be in the dump. You can skip this if you have a doubt/problem that is not related to some specific data, or if it can be reproduced using PostgreSQL system catalog tables.
Last but not less, a good description of your problem and the things you tried to solve it, if any. Please describe how we can reproduce your situation in order to allow us to fix/help you.

Obviously any data sent us remain private and be used solely for testing purposes and will be deleted as soon as your support request is considered done. Also, remember that the easiest to reproduce your problem, the easier for us to help you.

PostgreSQL	pgExpress	Obs
int2	TSmallIntField
int4	TIntegerField
oid	TIntegerField	As of pgExpress 4.30, OID fields will always be mapped and int4 to avoid confusion with Large Objects
int8	TLargeIntField/TStringField/TIntField	The dbExpress technology does not have native support for 64 bit integers; however, by using a hack, we provide native Int8 support. Please note the `TIndexDef` issues associated with native Int8 usage in the link here. This mapping is controlled by the Int8Mode Special Param.
char	TStringField	Fixed length. The same UNICODE/WideChar notes from varchar type apply.
varchar	TStringField/TWideString	`TStringField`.`Size` will be set to the maximum length. It's not adviced to set a maximum value too long in the table definition to keep the memory requirements low in the dbExpress row buffers. See here for details. If UnicodeAsWideChar is set to True, and the client encoding is UNICODE, the fields will be mapped as `TWideStringField`. If you want/need large values, try using the TEXT field type which maps into a BLOB/Memo (`TMemoField`) field. This field reads up to to 32kb (dbExpress limitation). varchar fields with no size specifier is identical to a text field and will be mapped in pgExpress just as a text field.
text	TBLOBField/Memo	Check our FAQ for more info on this. Text fields mapped as Memo will be faster and more efficient in terms of memory. You can also map them as strings (padded at 32Kb due to dbExpress limitation); check here.
xml	TBLOBField/Memo	See notes for text fields.
numeric	TFMTBCDField	VCL/CLX TFMTBCDFields support up to 32 digits. If you have a field with more then that, it will get mapped as TStringField.Note: TFMTBCDField is used instead of TBCDField because it allows greater precision.
time	TTimeField	See note below. The time field type support fractions.
timetz	TTimeField	Timezones and second fractions aren't supported by VCL/CLX and they can give your trouble when used in a WHERE clause on INSERT/UPDATE/DELETE queries. Please refer to our FAQ for more info.
date	TDateField	Timezones are not supported by VCL/CLX
timestamp	TTimeStampField	See note from fractions on the timetz field.
timestamptz	TSQLTimeStampField	See notes from timezones and fractions on the timetz field.
bool	TBooleanField
name	TStringField	Fixed length; name is a field type used internally by PostgreSQL.
bpchar	TStringField	Fixed length.
_bpchar	TStringField	Fixed length.
oid	TIntegerField	Integer
float4	TFloatField	Actually TFloatField can support more precision and scale then float4 fields and are recommended. You can teorically have a overflow or underflow if someone tries to insert a bad value.
float8	TFloatField
abstime/reltime	TTimeField	See note for time fields.
interval/tinterval	TStringField	Since there is no interval type in VCL, we have to map these types as strings.
bytea	TVarBytesField, Blob/Graphic or Blob/binary	See ByteaMode Special Param. TVarBytesFieldReads up to 32kb (dbExpress limitation).
money	TCurrencyField	The money field is obsolete. The PostgreSQL documentation advices to use numeric or float8 fields instead.
lo	TBlobField/Binary	Following the PostgreSQL ODBC driver convention, the 'lo' field represents Large Objects. Consider using Bytea fields as BLOBs instead.
Other	TStringField	Unknown fields are mapped by default as Strings. You can turn this off (and thus don't use the fields at all) by toggling the MapUnknownAsString special param.

Parameter	Obs.
DriverName
Database	Used also to provide Special Params to the pgExpress Driver. This parameter can also be used as an URL for providing extra host and port info: host:port/database Please check the Installation section for more details.
User_Name
Password	See also the Authentication section.
BlobSize	This parameter is actually ignored, since PostgreSQL can report the exact Blob field size.
LocaleCode	See also the Multibyte, UNICODE and Locales section.
RowsetSize	Only works if the BlockRead param is True.
HostName	Name can instead be specified as a member of the `Database` paramater.
RoleName	Will set a PostgreSQL7.3+ schema (namespace) to log in. Please check here for more details. Multiple Schemas can be specified (just as in PostgreSQL) if separated by collons, such as: RoleName = public,schema1,schema2
ServerCharset	See also Multibyte, UNICODE and Locales.
Custom String	This param allows to supply Special Params through a way other then the traditional, i.e. after the `Database`. D7+ only.
ServerPort	Allows setting the port to connect to. D7+ only. Can instead be specified as a member of the `Database` paramater.
ConnectionTimeout	The `ConnectionTimeout`Special Param can be used on Delphi 6/7 too, or Kylix. D7+ only.
BlockingMode	If False, asynchronous connections will be used to connect to the server.
Decimal Separator	Same as ServerDecimalSeparator, but since BDS 2006, it is also supported as a regular dbExpress parameter. It will not work with applications built with older IDEs.
ConnectionString	dbExpress applications (BDS 2006+), support a custom connection string, that will be passed directly to the `PQconnectdb()` function, and thus supporting anything that function supports. You can use that parameter instead of Database parameter, User_Name parameter, etc. Syntax will be the same as of the `conninfo` parameter of the `PQconnectdb()` function.
ErrorResourceFile	Allows to set the language resource file for the driver. Please refer to Multilanguage Driver section for more details. Notes: The behavior for this parameter has changed on pgExpress v3.0. To get the same behavior as the v2.X series, check the Language.
Trim Char	When True, trailing space chars CHAR fields will be trimmed. VCL/CLX default is False.

Information	Meaning	Function
GetPGVersion	Returns the PostgreSQL server version as a float.	GetPGVersion
TTY	Allows setting or retrieving file or TTY for optional debug output from the backend server. Set before connecting.	GetTTY
BackendPID	Will retrieve the PID of the process of the connection in the backend server.	GetBackendPID
Online	Will return `True` if a connection to the server exists. This implements the `eCommOnline` interface.	GetOnline

Encoding	Description
SQL_ASCII	ASCII
EUC_JP	Japanese EUC
EUC_CN	Chinese EUC
EUC_KR	Korean EUC
EUC_TW	Taiwan EUC
BIG5	Chinese BIG5
UNICODE	Unicode (UTF-8)
MULE_INTERNAL	Mule internal code
LATIN1	ISO 8859-1 ECMA-94 Latin Alphabet No.1
LATIN2	ISO 8859-2 ECMA-94 Latin Alphabet No.2
LATIN3	ISO 8859-3 ECMA-94 Latin Alphabet No.3
LATIN4	ISO 8859-4 ECMA-94 Latin Alphabet No.4
LATIN5	ISO 8859-9 ECMA-128 Latin Alphabet No.5
LATIN6	ISO 8859-10 ECMA-144 Latin Alphabet No.6
LATIN7	ISO 8859-13 Latin Alphabet No.7
LATIN8	ISO 8859-14 Latin Alphabet No.8
LATIN9	ISO 8859-15 Latin Alphabet No.9
LATIN10	ISO 8859-16 ASRO SR 14111 Latin Alphabet No.10
ISO-8859-5	ECMA-113 Latin/Cyrillic
ISO-8859-6	ECMA-114 Latin/Arabic
ISO-8859-7	ECMA-118 Latin/Greek
ISO-8859-8	ECMA-121 Latin/Hebrew
KOI8	KOI8-R(U)
WIN	Windows CP1251
ALT	Windows CP866

Language	Language Code
English	enUS
Portuguese (Brazilian)	ptBR

Supported Compilers:	D7+
Category:	Database Information
Unit:	PGEDriverUtils.pas

Supported Compilers:	Category:
Query Execution	Unit:
PGEDriverUtils.pas

Version 4.30 - Release Date: 22 Oct 2008
Bugfix release.
ADDED	Support for PostgreSQL's 8.3 UUID fields.
ADDED	Documentation enhancements.
ADDED	Enhanced multithreading functionality.
CHANGED	OID fields will always be mapped as int4. Please check OID type for details.
FIXED	Fixed GetProcedureParams() interface, what fixes store procedures usage under IDE.
FIXED	Fixed RoleName parameter under protocol 4.0 (Delphi 2007+).
FIXED	Fixed timestamp millisecond bug.

Version 4.22 - Release Date: 01 Apr 2008
Bugfix release.
FIXED	Fixed access violations in some particular situations.
FIXED	Fixed issues with timestamp fields under Delphi 2007.

Version 4.21 - Release Date: 23 Mar 2008
Bugfix release.
FIXED	Fixed random memory error / "Read of address FEEEFEEE in module 'libpq.dll'" messages.

Version 4.20 - Release Date: 06 Feb 2008
New major version.
ADDED	PostgreSQL 8.3 support. XML fields will be mapped the same way TEXT fields are, i.e. as Blob/Memo; Section 4, “Types Mappping” for details.
ADDED	Enhanced Delphi 2007+ support (dbExpress 4 support). Please see Installation on dbExpress 4.0 protocol (Delphi 2007+) for details. With that feature comes also new DBX4Compatible special param.
ADDED	Now the pgExpress Driver can generate large log messages (> 1024 bytes) (log messages can be captured by TSQLMonitor instances).
ADDED	Documentation enhancements.
FIXED	pgExpress won't refuse to work with 8.2.6 (or later) versions anymore.

Version 4.10 - Release Date: 06 Dec 2006
Maintenance release.
ADDED	Preliminar PostgreSQL v8.2 support. Please read the version-specific notes.
FIXED	Fixed a couple OUT parameters Stored Procedures problems.
FIXED	Fixed a problem in the GetProcedureParams interface.
FIXED	Documentation fixes.

Version 4.04 - Release Date: 01 Jun 2006
Maintenance release.
ADDED	Support for the EnterpriseDB.
FIXED	Int8Mode could be ignored on certain systems.

Version 4.02 - Release Date: 06 Mar 2006
Bugfix release.
ADDED	Added support for the VCL/CLX "Trim Char" parameter.
FIXED	Fixed a bug with string parameters on protocol v3.0 drivers.
FIXED	Fixed a bug on virtual cursor interfaces that could cause problems on the `GetColumnNames()` interface in and stored procedures.
FIXED	Fixed a bug with blob (bytea) parameters.

Version 4.01 - Release Date: 27 Jan 2006
Bugfix release.
FIXED	Fixed a couple bugs in the 4.00 version.

Version 4.00 - Release Date: 26 Jan 2006
New major version: BDS 2006 and UNICODE support.
ADDED	Added BDS 2006 compatibility. This includes support for protocol v3.0, unicode interfaces, native int64, enhanced dbExpress API. pgExpress is the first driver to add such support.
ADDED	Enhanced UNICODE support. Check also the UnicodeAsWideChar parameter. If you have problems opening bases with UNICODE encoding, add a client encoding to your `dbxconnections(.ini)` entry, such as: ServerCharset = /latin1 For more details, please refer to Section 1, “Multibyte, UNICODE and Locales”.
ADDED	With the introduction of protocol 3.0 support in BDS 2006, now we have two new drivers, `dbexpge30.dll` and `dbexpge30-ml.dll`, whose implement it. These drivers will work only on BDS 2006 and later. The regular pgExpress Driver which implements dbExpress protocol 2.5 still works with BDS 2006, but pgExpress protocol 3.0 won't work with applications built for older protocol implementations.
ADDED	Added UnicodeAsWideChar special param: will map char/varchar fields as `TWideString` fields. This will work only if the client encoding is UNICODE, and with protocol 3.0 or above.
ADDED	Added BorlandCompatible special param, which adds more compatility between pgExpress and Codegear drivers, on the NUMERIC mapping.
ADDED	Documentation enhancements.
ADDED	The following new interfaces are supported: eConnConnectionString eConnPrepareSQL eConnDecimalSeparator eConnEncrypted eConnMultipleTransaction eCommCursorName Most of these interfaces will only be recognized on BDS 2006 please check your IDE documentation for more details.
ADDED	The `libpq` library was updated to version 8.1.2, for both `Linux` and `Windows`.
CHANGED	Now if the client encoding is UNICODE and the application does not support that encoding (all compiled with compilers before BDS 2006), or do not user UnicodeAsWideChar, the pgExpress Driver will automatically set the client encoding to LATIN-1. While it should fit most users, it can be easily changed to any desired encoding value by using the ServerCharset parameter.
FIXED	Fixed a bug where the ByteaMode Special Param would not be recognized on all situations.
FIXED	Fixed `libpq` dependencies on `comerr32.dll` and other external libraries.
FIXED	Fixed `libpq` loading under Win9X.
FIXED	Fixed a licence bug on `Windows`.

pgExpress Driver 4.50

Steve Howe

IMPORTANT!!!! - About this documentation

Note

Chapter 1. Introduction

1. Introduction

2. History

3. Features and Highlights

4. Distributions

5. Demos

Note

Chapter 2. Using the pgExpress Driver

1. Requirements

1.1. Libpq

Note for libpq incompatibilities:

2. Installation

Note:

Notes:

2.1. dbExpress 4.0 (Delphi 2007+) support

Upgrading to Delphi 2007+

3. Protocols

dbExpress 4.0 support

4. Types Mappping

5. Customizing the pgExpress Driver

5.1. Driver Parameters

Notes:

5.2. Special Params

IMPORTANT:

Obs:

Note

Notes:

Obs:

Note

Note

Note

Note

5.3. Custom Info

6. Advanced Features

6.1. Stored Procedures Support

6.2. Fetch Cursors

Notes:

6.3. Authentication

6.4. Automatic numeric format detection

6.5. Native Int8 support

Important note about dbExpress usage with Int8 fields

6.6. Retaining Cursors

Note

6.7. BLOBs Support

6.7.1. Large Objects (BLOBs)

Important upgrade Note:

6.7.1.1. Large Object field declaration

Note

Note

6.7.1.2. Using Large Objects (BLOBs)

Notes:

Note

Tips:

6.7.2. Bytea fields as BLOBs

Important:

6.7.3. TEXT fields as BLOBs

Important:

6.8. SSL Support

6.9. NOTICEs support

Note

6.10. Asynchrounous connections

6.11. Canceling a query

Chapter 3. Localization

1. Multibyte, UNICODE and Locales

Note

2. Multilanguage Driver

Note

Note

Tip

3. Translating the pgExpress Driver

Note

Chapter 4. PGEDriverUtils.pas

GetPGVersion

Parameters:

Return Value:

Exceptions:

Note for `libpq` incompatibilities: