Devart Forums

Just thought I would post some wish list items for the future PostgreSQL version.

1. Unicode Suport: Delphi 2008 is coming and being able to encode/decode utf8 automaticly is critical. Commands sent to and from the server must also be supportedm, not just the data.

2. Ability to receive notices from the server. The server emits notices for many things, for example to run db maintenance and be able to see what is going on you need to be able to receive notices. In order to code interfaces for the 8.3 debugger you have to be able to receive notices.

3. Direct TCP/IP mode like the MyDAC and PostgreSQL .net data provider.

4. Ability to treat OIDs as integers

5. Large OID support. This is critical for Servers that have been running for a long time, either use int64 or cardinal types to store OIDs.

6. Options for using the built in SSL support for Libpq.dll


A backup and restore componet that does not use Libpq dlls would be nice as well.

If the first five can be incorporated into the 1.0 release you will have a real winner.

Thank you for your assistance. Your 1, 2, 3, 4 propositions will be supported in the first version of PgDAC. SSL support will be provided with our product SecureBridge. We are not sure that Large OID support, backup and restore componets will be available in the first version of PgDAC, but more information on this we will provide a bit later.

Challenger wrote:Thank you for your assistance. Your 1, 2, 3, 4 propositions will be supported in the first version of PgDAC. SSL support will be provided with our product SecureBridge. We are not sure that Large OID support, backup and restore componets will be available in the first version of PgDAC, but more information on this we will provide a bit later.

Wow, can't wait for it to be released

For large OID support I think you simply need to use cardinal instead of integer when dealing with OIDS. Int64 would also work fine, but I am not sure how far back Delphi goes with Int64 support. PG Servers that have been running for a long time can have OIDs that won't fit in a standard 32bit integer. standard integer(signed) will roll over:
-2147483648..2147483647

Cardinal (unsigned) can go to the full 32bit range of 0..4294967295

Int64 would probably be the best in order to be future proof.

So will native client dlls (libpq.dll in this case) also be available as a option as in the MyDAC product?

Backup and restore componens are not a critical thing as it's easy enough to do with pg_dump/restore and create process, but in the future it would be very cool if dumps and restores could be done via the direct conect, that way you wouldn't have to deploy all the libpq dependencies.

Overall what you have planned for a 1.0 release sounds excellent.

Thank you for the information

Now we do not see any reasons to support libpq.dll. So the first release of PgDAC will support direct connecting only.

Challenger wrote:Now we do not see any reasons to support libpq.dll. So the first release of PgDAC will support direct connecting only.

I guess that makes sense and sounds alright by me.

This is excellent news. I've been waiting a long time for Core Lab to release a VCL DAC for PostgreSQL.

I started out with your MyDAC product and have always been happy with Core Lab, but when we switched to PostgreSQL, we had to start using DACs from other companies.

I'll be happy to switch back to Core Lab.

We have released UniDAC 2 Beta with PostgreSQL support. We are looking forward to your comments and suggestions.