[fpc-devel] pqconnection.pp Code Review Needed Int64 data types not supported in PostgreSQL

[Michael Van Canneyt]

On Thu, 21 Oct 2010, Andrew Brunner wrote:

> 1.) Say you have a string of certain length 25
> 2.) And you have a memory block of 26.
> 3.) You move Pchar(s) into ar[i] but read beyond the length of the string
>
>          //GetMem(ar[i],length(s)+1);
>          //StrMove(PChar(ar[i]),Pchar(s),Length(S)+1);
>
>
>          iLen:=length(s);
>          GetMem(ar[i],iLen+1);
>          FillByte(ar[i]^,iLen+1,0);
>          StrMove(PChar(ar[i]),Pchar(s),iLen);
>
> These clearly do the same thing.  But what happens when you read past
> the length of a string? Is it safe?
>
> The first block is actual code from the postgresql database component.

This is because it also copies the null-terminating character which is present after the string.
It is normal.

> As of right now the PostgreSQL component does not handle Int64
> dataype and is crippling any use of the DBMS.

'any' is a bit strong - only if you use the Int64 type you're 'crippled'.
(and admittedly, severely crippled)

> If MySQL and PostgreSQL
> are broken - I just don't see the point of supporting SQL DBMSes.
> Is there a massive reworking in the SQL area of FPC underway causing
> the lack of quality for the diverse versions of the most popular sql
> servers available?

None is planned. The Interbase/Firebird component access is in production 
use for a long time; with no known issues currently. It is the recommended 
database with FPC/Lazarus.

As far as I know, PostGres is also in production use; but if the users don't 
use Int64, they may never have encountered this issue.

The use of MySQL with Free Pascal is not broken AFAIK, but not recommended 
because of their quite unstable API. See the numerous mails about this on 
the various FPC mailing lists.

If there are specific issues with MySQL or PostGres, please report them.
(in casu, the Int64 issue) We'll try to fix them ASAP.

Michael.