We've released the first public beta for our new major version of PostgresDAC component suite. It’s been a long way started almost two years ago. The goals were complicated, and not all of them were accomplished. However, in general we may proudly say without a doubt that this release is a significant milestone.
Dump and restore functionality
TPSQLDump and TPSQLRestore components is a pair that is one of a kind on the whole market. There are no more such facilities not only in the Delphi or C Builder world, but for any other IDE's or toolchains. That is why our first goal was to keep this classes up to date. A huge amount of work was done and a year ago the brand new v3 TPSQLDump and TPSQLRestore components were published as part of v2.11.0 release.
TPSQLDump and TPSQLRestore are fully compatible with native pg_dump and pg_restore utilities. Each and every native feature is supported out of the box:
- output formats (binary, text, directory, gzipped),
- parallel dumping and restoring,
- comprehensive selection, filtering and reordering of archived items,
- SQL-92 specific output options, etc.
Asynchronous Fetch-On-Demand mode
The default TPSQLQuery's mode is suitable for submitting commands and getting result sets in normal, synchronous applications. However, there are few drawbacks, that may be of importance to developers:
- TPSQLQuery.Open waits for the command to be completed. The application might have other work to do (such as maintaining a user interface), in which case it won’t be a good decision to block while waiting for a response.
- Since the execution of the client application is suspended while it waits for the result, it is hard for the application to decide that it would like to try to cancel the ongoing command.
- TPSQLQuery in default mode always collects a command's entire result, buffering it in a single place. While this behavior simplifies some internal logic, it can be impractical for results containing many rows.
To avoid such limitations developers now can use the brand new Fetch-On-Demand mode, which is turned on by dsoFetchOnDemand option in the TPSQLQuery.Options set.
There are limitations of course:
- To get advantages of the Fetch-On-Demand mode one should use read-only TPSQLQuery objects. This restriction will be removed with time probably.
- Each read-only TPSQLQuery component must have its separate TPSQLDatabase component since Fetch-On-Demand command flow will block a connection until getting the last row of the result set.
Support for built-in range and geometric field types
Previously these specific types were mapped to TStringField class. Now PostgresDAC provides new TField descendants for this:
All of them will be created automatically if needed, or may be added manually in design time.
TPSQLRangeField encapsulates all built-in PostgreSQL range types: int4range, int8range, numrange, tsrange, tstzrange and daterange. Information about range value is stored in the TPSQLRange record by storing values for each bound using TPSQLRangeBound record. Depending on the underlying table field type developer may access bound values using appropriate methods AsInteger, AsFloat, etc.
Right now, we are working on the new help system. Our team is rewriting it from scratch. There is still lack of some topics, especially about new v3 features. However, we are hoping new manual will be ready till the next beta or release candidate. We are planning support for such formats:
You're welcome to download the latest beta right now at:
or login to your private area on our site at
We are looking forward to hearing back from you, our beta testers, at your earliest convenience.
Please don't hesitate to ask any questions or report bugs with our Support Ticketing system available at