Hi Graeme,<br><br>The libpq_api.pas that ships with FPC implements all the functions from the version 3 native api on windows and linux. This .so/.dll is backwards compatible even with the latest versions of postgresql server.<br>
<br>I tried TPQConnection in a production environment on a server-side deamon, and bytea was the first missing data type that haunted me. The "encode" postgres function will save you here: Encode your bytea field to hex, then run a hextobin afterwards. (Sorry if you use dbAware components in this case). Some other field types were missing as well, I did not try further with this component and I'm hoping for more developments in the future as well.<br>
<br>I also tried Zeos db components. They work with FPC very well, and the bytea type encodes all characters correct when using TField.AsString, but there was this massive memory leak somewhere when opening a dataset every time. The leak was so bad it made the daemon unfit for production running. The Zeos forum at that time laid the blame with FPC's TDataSet class, but I could not bother to investigate if this was so or not. I was pressed for time to release the software.<br>
<br>Because the version 3 API is so simple, it was too easy to use the libpq_api.pas wrapper that comes with FPC, write a TDBConnection, TQuery and TField (with the .As* functions for data types I needed) that compiled nicely up to the TDataSet code compatibility. Of course, the code is not usable to dbAware components because it is not a descendant of TDataSet, but, it worked for everything I needed in those daemons, it is lightweight and stable. !!<i>No support for parameters and prepared statements</i>!!<br>
<br>Judging from my experience, I think the FPC developers, given enough time, can do some good work with their own TPQConnection, seeing that I'm still a novice pascal programmer. If you are interested in my code, I can publish somewhere and send you a url.<br>
<br>Desmond<br><br><div class="gmail_quote">On Sun, Aug 16, 2009 at 10:11 PM, Graeme Geldenhuys <span dir="ltr"><<a href="mailto:graemeg.lists@gmail.com">graemeg.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/8/16 Joost van der Sluis <<a href="mailto:joost@cnoc.nl">joost@cnoc.nl</a>>:<br>
<div class="im">> But it's this way because nobody looked at it before, and all those<br>
> things like column_datatype are effectively used by no-body, afaik. But<br>
> patches are welcome. (The only reason this function is implemented at<br>
> all is that it is used by Connection.getTableNames and .GetFieldNames.)<br>
<br>
</div>So is SqlDB+PostgreSQL not tested or Alpha / Beta quality? I was<br>
hoping to use it in a production environment. PostgreSQL seems to be a<br>
lot more powerful than other open source database + the PostgreSQL<br>
tools like pgAdmin III are brilliant.<br>
<div class="im"><br>
<br>
> This probably didn't exist when this code was written (postgres 5) and<br>
> the information_schema is probably just a view which references to<br>
> pg_attribute...<br>
<br>
</div>Yes, any implementation of "information_schema" is normally a view.<br>
The nice thing is that even if the underlying system tables change,<br>
the information_schema views will not. Hence the reason it is<br>
preferable to use the information_schema's if they exist, instead of<br>
querying the system tables directly.<br>
<br>
Is it still worth supporting anything before PostgreSQL 7.2 - as far<br>
as I can see many major changes (for the better) occurred after 7.2<br>
and 8.0. Hey, the database server is free, so there shouldn't be any<br>
reason not to upgrade. :-)<br>
<div class="im"><br>
<br>
> Could be. In fact, Bytea is not a blob field. So to support blob-fields,<br>
<br>
</div>All the documentation I read suggests that Bytea is used for BLOB<br>
types. And Firebird's "blob subtype 1" is equal to "Text" in<br>
PostgreSQL.<br>
<div class="im"><br>
<br>
> the databases you are used to use. (For blob-fields Postgresql ask you<br>
> to use a plain number-field in which you store the blob-id, and then use<br>
> seperate functions to retrieve the blob-data.<br>
<br>
</div>As far as I understood the documentation, that is all handled<br>
internally by PostgreSQL. Users do not need to worry about something<br>
like that, you use Bytea just like any other field type. The server<br>
stores BLOB (bytea) data in a separate location to overcome the table<br>
row size limit. Internally a reference is used in the users table, but<br>
the end user never sees that.<br>
<div class="im"><br>
<br>
> But please create bug-reports, preferrably with actual user-case<br>
> problems, not only based on the code, but also show the results. That<br>
> way we can find some way to be as compatible possible with other<br>
> databases like Firebird.<br>
<br>
</div>Will do - expect many patches. I'm determined to get Free Pascal to<br>
pass the extensive test suite of tiOPF.  The database test suite gives<br>
the DB components a very good workout. SqlDB+Firebird is doing pretty<br>
well, but SqlDB+PostgreSQL still fails a lot of tests. Both are not<br>
100% pass rate, but hopefully when I am done, they will be.<br>
<div class="im"><br>
<br>
<br>
Regards,<br>
  - Graeme -<br>
<br>
<br>
_______________________________________________<br>
fpGUI - a cross-platform Free Pascal GUI toolkit<br>
<a href="http://opensoft.homeip.net/fpgui/" target="_blank">http://opensoft.homeip.net/fpgui/</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br>
</div></div></blockquote></div><br>