PostgresDAC meets PostgreSQL 8.4


Oh, it was quite long time for 8.4 version of PostgreSQL to finally get up on it’s feet and stand firmly – 16 months. After a sixteen-month pregnancy, the development team gave birth to a pretty elephant calf. Well done guys!

At the very same day development team of PostgresDAC – the newborn calf’s friend 🙂 – decided to release PostgresDAC 2.5.2 Beta with support for 8.4 server features. And that’s not just an advertising words.

Crux of the matter

We’ve prepared v2.5.2 Beta with a lot of improvements. It was passed our internal tests but this is still beta version.

The main changes directly related to PostgreSQL 8.4 release would be:

  • 8.4 SSL Authentication is implemented
  • TPSQLRestore now supports 8.4 parallel restore
  • 8.4 clients libraries are used including dump\restore libs
  • TPSQLRestore and TPSQLDump 8.4 support includes (see Release Notes for details, section E.
    • roNoTablespace and doNoTablespace options added
    • doIgnoreVersion & roIgnoreVersion options marked as deprecated
    • TPSQLDump.LockWaitTimeout property added
    • Role properties added

From others features without a doubt should be mentioned:

  • TPSQLDataset.Options property added for fine tuning of component behavior
  • TPSQLDatabase.DesignOptions property added for absolute control over stored properties
  • Extended SQL editor for TPSQLQuery added with tables and fields list
  • Special TPSQLGuidField class added


It is worth noting that there were only two bug reports – and they were fixed – in this release and only one was developers’ fault, the other one appeared due to internal changes of Delphi 2009 after Update 3\4.

May the Force be with you, postgresmen!


Is SSL in use?


SSL connection option may be one of the four values: disable will attempt only an unencrypted SSL connection; allow will negotiate, trying first a non-SSL connection, then if that fails, trying an SSL connection; prefer (the default) will negotiate, trying first an SSL connection, then if that fails, trying a regular non-SSL connection; require will try only an SSL connection.

Hence it may happen that one can’t know for sure if an SSL connection is negotiated with the server. How can we check this?

Using SQL

If we have only administration tool (psql, pgAdmin etc.) then the decision is to use sslinfo module shipped with PostgreSQL installation. If you didn’t check option to include this module during PostgreSQL server installation, you always may manually execute sslinfo.sql script situated in ‘$libdir/share/contrib’ directory.

Or if you are minimalist just execute such statement:

AS '$libdir/sslinfo', 'ssl_is_used'

And then:

/*Mirror, Mirror on the wall.
Is SSL in use at all?*/

SELECT ssl_is_used();

Using libpq – C Library

If you’re developer then using libpq library will help you a lot to answer this question. Here we have PQgetssl function, which returns the SSL structure used in the connection, or null if SSL is not in use.

SSL *PQgetssl(const PGconn *conn);

Though this definition is canonical, to use it we must also include ssl.h from OpenSSL. I’m not sure if C will allow such trick:

void *PQgetssl(const PGconn *conn);

But Delphi will:

function PQgetssl(conn: PGconn): pointer;

So assumed that LoadLibrary called already, GetProcAddress either. Then to know if SSL is in use:

function IsSSLUsed: boolean;
var P: pointer;
    FHandle: PPGconn;
  FHandle := PQconnectdb(...);
  P := PQgetssl(FHandle);
  Result := P <> nil;

Using PostgresDAC

If you’re happy owner of the PostgresDAC suite then starting from 2.5.1 release you may check

property TPSQLDatabase.IsSSLUsed: Boolean