Re: Can someone explain the current state of BLOB fields and Postgres ODBC?

I'm going to assume that the lack of response is due to people being away
on holiday enjoying the summer weather or just don't know the answer.. I
believe I found the proper solution for this and wanted to share it. Feel
free to disagree and set me straight :)

It seems this whole escape sequence stuff is nearly legacy support for the
old Postgres (and even Ingres?) support for specifying control codes
inline in a sql statement. This support appears to be slowly removed in
favor of being more ANSI compliant. To that end, the solution is to
enable the database parameter standard_conforming_strings (set it to yes).
This will disable support for the escape sequences, allowing ODBC apps to
behave as you would expect.

Can anyone confirm this? Also, are there other parameters that I should
look at to make my ODBC experience more "standard"? We do have the
ability to add workarounds for specific drivers, but I feel that "less is
more".

Thanks and enjoy your weekends..

Jon

From:
raiford(at)labware(dot)com
To:
pgsql-odbc(at)postgresql(dot)org
Date:
06/17/2010 01:17 PM
Subject:
[ODBC] Can someone explain the current state of BLOB fields and Postgres
ODBC?
Sent by:
pgsql-odbc-owner(at)postgresql(dot)org

We have an ODBC application that among other things needs to be able to
read and write binary files to the database. Originally I tried using oid
fields, but now it looks like bytea with the "bytea as lo" parameter is
the recommended way. From my searching on Google, there seems to be a lot
of information (mostly old) that talks about oid, bytea, and lo, and I'm
now pretty confused. Can anyone clear this up for me?

When working with BLOBs we always use bind parameters and if the binary
data is over 2500 bytes, we read or write the data in chunks. This all
seems to work ok, but when writing files to the database, its returning
the warning message "WARNING: nonstandard use of escape in a string
literal". When I pull the files out, they still seem to look ok, but I'm
worried that something is trying to interpret the data instead of just
passing it in directly. Is it safe to ignore this warning? Or is it
possible that data corruption could occur?

Jon