Quick Links

Re: BLOB handling compatibility with PostgreSQL > 7.4

Lists:	pgsql-interfacespgsql-odbc

From:	Irina Sourikova <irina(at)bnl(dot)gov>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-11-28 21:39:57
Message-ID:	438B792D.6030802@bnl.gov
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Dear experts,

We would like to upgrade the Postgres version from our current 7.3 but
have problems with handling BLOBs via ODBC.
We use unixODBC-2.2.11 and psqlodbc-08.01.0101.
With postgres 7.3 lo type was mapped to SQL_C_BINARY and that's changed
since postgres 7.4.
Is it an ODBC or a driver issue? Are there any plans to fix the problem?

Thank you,
Irina

--
Irina Sourikova
Brookhaven National Laboratory phone: +1-631-344-3776
Physics Department, Bldg 510 C fax: +1-631-344-3253
Upton, NY 11973-5000 email: irina(at)bnl(dot)gov

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Irina Sourikova <irina(at)bnl(dot)gov>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-11-30 09:45:09
Message-ID:	20051130094509.GA6109@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> We use unixODBC-2.2.11 and psqlodbc-08.01.0101.

I don't exactly know how it's on linux. But which version of psqlodbc
do you use (unicode x ansi). Try the second type and let us know
if it helps.

> With postgres 7.3 lo type was mapped to SQL_C_BINARY and that's changed
> since postgres 7.4.

That's changed to what type?

Luf

From:	Irina Sourikova <irina(at)bnl(dot)gov>
To:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-11-30 19:16:12
Message-ID:	438DFA7C.8040804@bnl.gov
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I compiled psqlodbc with --enable-unicode=no , didn't help. 
 
I'll try to give some details: 
 
On 2 postgres servers ( running 7.3.6 and 7.4.2 ) I did the following: 
 
create domain lo as oid; 
create table justlo(b lo); 
 
Then  I inserted an entry from a text file via a program that uses
libodbc++ ( attached below ) 
insert into justlo values(lo_import('/usr/local/pgsql/text.txt')) 
 
The following 2 programs ( first uses libodbc++, second - plain ODBC )
run fine when connecting to postgres 7.3 and crash with postgres 7.4: 
/* 
 odbc++ example 
*/ 
#include <sstream> 
#include <iostream> 
#include <string> 
#include <odbc++/connection.h> 
#include <odbc++/setup.h> 
#include <odbc++/types.h> 
#include <odbc++/errorhandler.h> 
#include <sql.h> 
#include <odbc++/drivermanager.h> 
#include <odbc++/resultset.h> 
#include <odbc++/resultsetmetadata.h> 
#include <odbc++/preparedstatement.h> 
#include <odbc++/databasemetadata.h> 
#include <fstream> 
 
using namespace odbc; 
using namespace std; 
 
int main(int argc, char *argv[]) 
{ 
  Connection* con = 0; 
  Statement* stmt = 0; 
  ResultSet* rs = 0; 
  string query; 
  unsigned int numcol; 
 
  try 
    { 
       con = DriverManager::getConnection("test74", "postgres", ""); 
       //con = DriverManager::getConnection("test", "postgres", ""); 
      cout << con->getMetaData()->getDriverVersion()
<< endl; 
    } 
  catch (SQLException& e) 
    { 
      cout << e.getMessage() << endl; 
      return 1; 
    } 
  
  //on nuvi, postgreSQL 7.3.6 
  query = "insert into justlo
values(lo_import('/usr/local/pgsql/text.txt'))"; 
  //on sql, postgreSQL 7.4.2 
  //query = "insert into justlo
values(lo_import('/var/lib/pgsql/text.txt'))"; 
 
  stmt = con->createStatement(); 
  try{ 
    //stmt->executeUpdate(query.c_str()); 
  } 
  catch (SQLException& e) 
    { 
      cout << e.getMessage() << endl; 
      return 1; 
    } 
  
  query = "select * from justlo"; 
  stmt = con->createStatement(); 
  try{ 
    rs = stmt->executeQuery(query.c_str()); 
  } 
  catch (SQLException& e) 
    { 
      cout << e.getMessage() << endl; 
      return 1; 
    } 
  
  char str[50]; 
  while( rs->next()){    
    istream * ms = rs->getBinaryStream(1); 
    ms->getline(str,50); 
    cout << str << endl; 
  } 
 
  delete con; 
  return 0; 
} 
 
======================== 
/* odbc.c 
testing psqlodbc with postgreSQL 7.3.6 and 7.4.2 
*/ 
#include <stdlib.h> 
#include <stdio.h> 
#include <sql.h> 
#include <sqlext.h> 
#include <sqltypes.h> 
 
SQLHENV             V_OD_Env;     // Handle ODBC environment 
long             V_OD_erg;     // result of functions 
SQLHDBC             V_OD_hdbc;    // Handle connection 
char             V_OD_stat[10]; // Status SQL 
SQLINTEGER         V_OD_err,V_OD_rowanz,V_OD_id; 
SQLSMALLINT         V_OD_mlen; 
char                     V_OD_msg[200],V_OD_buffer[200]; 
SQLHSTMT                 V_OD_hstmt;   // Handle for a statement 
SQLINTEGER               V_OD_err,V_OD_id; 
char                     V_OD_buffer[200]; 
 
int main(int argc,char *argv[]) 
{ 
  // 1. allocate Environment handle and register version 
  V_OD_erg=SQLAllocHandle(SQL_HANDLE_ENV,SQL_NULL_HANDLE,&V_OD_Env); 
  if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg !=
SQL_SUCCESS_WITH_INFO)) 
    { 
      printf("Error AllocHandle\n"); 
      exit(0); 
    } 
  V_OD_erg=SQLSetEnvAttr(V_OD_Env, SQL_ATTR_ODBC_VERSION, 
             (void*)SQL_OV_ODBC3, 0); 
  if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg !=
SQL_SUCCESS_WITH_INFO)) 
    { 
      printf("Error SetEnv\n"); 
      SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env); 
      exit(0); 
    } 
  // 2. allocate connection handle, set timeout 
  V_OD_erg = SQLAllocHandle(SQL_HANDLE_DBC, V_OD_Env, &V_OD_hdbc); 
  if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg !=
SQL_SUCCESS_WITH_INFO)) 
    { 
      printf("Error AllocHDB %d\n",V_OD_erg); 
      SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env); 
      exit(0); 
    } 
  SQLSetConnectAttr(V_OD_hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER *)5, 0); 
  // 3. Connect to the datasource "test" 
  V_OD_erg = SQLConnect(V_OD_hdbc, (SQLCHAR*) "test", SQL_NTS, 
            (SQLCHAR*) "postgres", SQL_NTS, 
            (SQLCHAR*) "", SQL_NTS); 
  if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg !=
SQL_SUCCESS_WITH_INFO)) 
    { 
      printf("Error SQLConnect %d\n",V_OD_erg); 
      SQLGetDiagRec(SQL_HANDLE_DBC, V_OD_hdbc,1, 
            V_OD_stat, &V_OD_err,V_OD_msg,100,&V_OD_mlen); 
      printf("%s (%d)\n",V_OD_msg,V_OD_err); 
      SQLFreeHandle(SQL_HANDLE_DBC, V_OD_hdbc); 
      SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env); 
      exit(0); 
    } 
  printf("Connected !\n"); 
 
  SQLRETURN retcode; 
  SQLHSTMT hstmt; 
  SQLCHAR       BinaryPtr[50]; 
  SQLINTEGER     BinaryLen; 
 
  SQLAllocHandle(SQL_HANDLE_STMT, V_OD_hdbc, &hstmt); 
 
  retcode = SQLExecDirect(hstmt,"SELECT b  FROM justlo",SQL_NTS); 
 
  if (retcode == SQL_SUCCESS) { 
    retcode = SQLFetch(hstmt); 
    if (retcode == SQL_ERROR || retcode == SQL_SUCCESS_WITH_INFO) { 
      printf(" error \n" ); 
    } 
    if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO){ 
      SQLGetData(hstmt, 1, SQL_C_BINARY, BinaryPtr,
sizeof(BinaryPtr),&BinaryLen); 
      printf( " %d, %s ",  BinaryLen, BinaryPtr); 
    } 
  } 
  else{ 
    printf(" error on select\n" ); 
  } 
} 
=================================================== 
 
I tried to debug and put som code into odbc++, here is the difference
between 2 postgres versions: 
 
with 7.3, no problem: 
 
entering getBinaryStream 
DataHandler::getStream. cType_: -2  sqlType -4 
 
with 7.4, segfault: 
 
entering getBinaryStream 
DataHandler::getStream. cType_: 4  sqlType 4 
UNSUPPORTED_GET 
[libodbc++]: Could not get SQL type 4 (INTEGER), C type 4 (SQL_C_LONG)
as an stream 
 
Hope this helps. 
Thanks, 
Irina 
 
Ludek Finstrle wrote: 
<blockquote type="cite"
cite="mid20051130094509(dot)GA6109(at)soptik(dot)pzkagis(dot)cz">
<blockquote type="cite">
<pre wrap="">We use unixODBC-2.2.11 and psqlodbc-08.01.0101.
</pre>
</blockquote>
<pre wrap="">
I don't exactly know how it's on linux. But which version of psqlodbc
do you use (unicode x ansi). Try the second type and let us know
if it helps.

</pre>
<blockquote type="cite">
<pre wrap="">With postgres 7.3 lo type was mapped to SQL_C_BINARY and that's changed
since postgres 7.4.
</pre>
</blockquote>
<pre wrap="">
That's changed to what type?

Luf

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
</pre>
</blockquote>
 
<pre class="moz-signature" cols="72">--
Irina Sourikova
Brookhaven National Laboratory phone: +1-631-344-3776
Physics Department, Bldg 510 C fax: +1-631-344-3253
Upton, NY 11973-5000 email: <a class="moz-txt-link-abbreviated" href="mailto:irina(at)bnl(dot)gov">irina(at)bnl(dot)gov</a>
</pre>
</body>
</html>

Attachment	Content-Type	Size
unknown_filename	text/html	10.0 KB

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Irina Sourikova <irina(at)bnl(dot)gov>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-01 13:04:06
Message-ID:	20051201130406.GA13995@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Hello,

could you try newer version of psqlodbc? There is version 8.01.0102
or try using CVS version, please.
I need to know your psqlodbc settings and backend encoding.

I have no time for this problem till end of week so be patient.

Luf

From:	"Chris Moore" <chrismoore(at)surewest(dot)net>
To:	<pgsql-odbc(at)postgresql(dot)org>
Subject:	Data showing up as #Deleted in Access
Date:	2005-12-01 15:35:00
Message-ID:	20051201154138.925069DD685@postgresql.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

I'm trying to get ODBC working for the first time so that I can access
a Postgres database from Access. I'm running PostgrSQL 8.0.3, PostgreSQL
ODBC 8.01.01.01, and Access 2003 version 11.6355.6360 SP1. The database
is on a system running RedHat Linux 2.6.9-6.37-EL and the client is running
Windows XP SP2.

When I try to open the ODBC data source in Access I see the list of tables
correctly. If I pick one of the tables and open it I get the correct field
names and the correct number of rows, but every field in every row says
"#Deleted"
instead of having data.

Can anyone suggest what might be wrong?

Thanks,

Chris

From:	"Campbell, Greg" <greg(dot)campbell(at)us(dot)michelin(dot)com>
To:	Chris Moore <chrismoore(at)surewest(dot)net>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-01 17:24:19
Message-ID:	438F31C3.4020205@us.michelin.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Access is trying to maintain an updateable recordset when you just open a table.
For an updateable table it need to be able to identify each record, in case you trying to change a value
on the record.
So it tries to determine if there is a primary key or by matching each field, can it determine a virtual
primary key.
If it knows the record "was/is" there but cannot determine a primary key, it says deleted -- This may not
be exact in the detail, but seems to be the principle.

The situation is usually aided by having tables with good primary keys. If you change the indexes or keys,
update the linked table in Access.
It is also helped sometimes by turning on row-versioning for the connection -- I usually use the ODBC
administrator and then use Access to refresh the linked tables, or drop and re-link the tables.

If these steps do not help, post a response for more help. You can also search this mailing lists website
archives for the "deleted" thing.

Chris Moore wrote:

> I'm trying to get ODBC working for the first time so that I can access
> a Postgres database from Access. I'm running PostgrSQL 8.0.3, PostgreSQL
> ODBC 8.01.01.01, and Access 2003 version 11.6355.6360 SP1. The database
> is on a system running RedHat Linux 2.6.9-6.37-EL and the client is running
> Windows XP SP2.
>
> When I try to open the ODBC data source in Access I see the list of tables
> correctly. If I pick one of the tables and open it I get the correct field
> names and the correct number of rows, but every field in every row says
> "#Deleted"
> instead of having data.
>
> Can anyone suggest what might be wrong?
>
> Thanks,
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

Attachment	Content-Type	Size
greg.campbell.vcf	text/x-vcard	241 bytes

From:	"Chris Moore" <chrismoore(at)surewest(dot)net>
To:	"'Campbell, Greg'" <greg(dot)campbell(at)us(dot)michelin(dot)com>
Cc:	<pgsql-odbc(at)postgresql(dot)org>
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-01 18:40:48
Message-ID:	20051201184050.C803A9DD43B@postgresql.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

I verified that the primary key was correct, and also turned on
row versioning, but still got the same thing.

Then I noticed that it was only one particular table that was having
problems. It occurred to me that this table had several fields of
type "text", one of which had rows in which this field had close to
a thousand characters in it. I changed all the "text" fields to
"varchar", making the one big one a varchar(2048). That seems to have
fixed the problem.

By the way, I did try searching for "#Deleted", but the search engine
tries to be helpful and also find instances of "delete", "deleting",
etc. There were just too many hits to be able to weed through them
all and find the relevant ones.

Thanks for your help.

Chris

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Chris Moore <chrismoore(at)surewest(dot)net>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-01 19:59:32
Message-ID:	20051201195932.GA16735@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> Then I noticed that it was only one particular table that was having
> problems. It occurred to me that this table had several fields of
> type "text", one of which had rows in which this field had close to

It seems current ODBC driver has problem with "text". Please could
you fill bug report with attached mylog output to psqlodbc bug
tracker at pgFoundry.org?
You could attach minimalistic exe file with table specification. It
helps us reproduce the problem by us.

Thanks

Luf

From:	"Zlatko Matic" <zlatko(dot)matic1(at)sb(dot)t-com(dot)hr>
To:	"Chris Moore" <chrismoore(at)surewest(dot)net>, "'Campbell, Greg'" <greg(dot)campbell(at)us(dot)michelin(dot)com>
Cc:	<pgsql-odbc(at)postgresql(dot)org>
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-02 10:02:11
Message-ID:	006b01c5f727$7711d610$52bffea9@zlatkovyfkpgz6
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Hello.
Just redesign your database. You need to have numeric primary key field in
every table. Don't use any other type as primary key, especially not any
kind of textual fields, because Access won't be able to refresh data
properly and you will face "#Deleted", which is very common problem with
Access/ODBC linked tables. You can find an article about "#Deleted" on
www.microsoft.com, too.
The best way to avoid "#Deleted" is to have a serial field (autonumber) as
primary key, in every table. That will solve your problem forever.

Zlatko

----- Original Message -----
From: "Chris Moore" <chrismoore(at)surewest(dot)net>
To: "'Campbell, Greg'" <greg(dot)campbell(at)us(dot)michelin(dot)com>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Sent: Thursday, December 01, 2005 7:40 PM
Subject: Re: [ODBC] Data showing up as #Deleted in Access

>I verified that the primary key was correct, and also turned on
> row versioning, but still got the same thing.
>
> Then I noticed that it was only one particular table that was having
> problems. It occurred to me that this table had several fields of
> type "text", one of which had rows in which this field had close to
> a thousand characters in it. I changed all the "text" fields to
> "varchar", making the one big one a varchar(2048). That seems to have
> fixed the problem.
>
> By the way, I did try searching for "#Deleted", but the search engine
> tries to be helpful and also find instances of "delete", "deleting",
> etc. There were just too many hits to be able to weed through them
> all and find the relevant ones.
>
> Thanks for your help.
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match

From:	"Andrus" <eetasoft(at)online(dot)ee>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-02 10:19:55
Message-ID:	dmp74e$11ub$1@news.hub.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

"Ludek Finstrle" <luf(at)pzkagis(dot)cz> wrote in message
news:20051201195932(dot)GA16735(at)soptik(dot)pzkagis(dot)cz(dot)(dot)(dot)
>> Then I noticed that it was only one particular table that was having
>> problems. It occurred to me that this table had several fields of
>> type "text", one of which had rows in which this field had close to
>
> It seems current ODBC driver has problem with "text". Please could
> you fill bug report with attached mylog output to psqlodbc bug
> tracker at pgFoundry.org?
> You could attach minimalistic exe file with table specification. It
> helps us reproduce the problem by us.

Luf,

my problem in thread "application crash after error" occurs also only with
text field.
So this may be the same problem .

Andrus

From:	"Miguel Juan" <mjuan(at)cibal(dot)es>
To:	<pgsql-odbc(at)postgresql(dot)org>
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-02 10:35:26
Message-ID:	00ed01c5f72c$1c1a3b30$07c8a8c0@Miguel
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Hello,

There is a workaround, just check the "Show OID column" and "Fake index" in
the ODBC configuration.

This used to work for me (some time ago, I must say).

Regards,

Miguel Juan

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Andrus <eetasoft(at)online(dot)ee>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-02 10:38:24
Message-ID:	20051202103824.GA21226@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> my problem in thread "application crash after error" occurs also only with
> text field.
> So this may be the same problem .

I don't think so. Your problem is specific. I try to describe it as
good as I can. I hope Dave or another guru can show me the right way.
I can correct your problem but I don't know if it doesn't break
another scenario ...
I don't give my hand off your problem. I only need advice from someone
who knows ODBC (not psqlODBC) better.

Hmmm. I get idea right now. I'll try it againist MySQL. It's ODBC is
open source so I can learn from it ...
Please could you change your example to support MySQL ODBC?
Maybe (or maybe not) it helps.

So please be patient I'm doing everything I can

Luf

From:	"Andrus" <eetasoft(at)online(dot)ee>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Data showing up as #Deleted in Access
Date:	2005-12-02 11:24:10
Message-ID:	dmpast$1nnt$1@news.hub.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek,

> Hmmm. I get idea right now. I'll try it againist MySQL. It's ODBC is
> open source so I can learn from it ...
> Please could you change your example to support MySQL ODBC?
> Maybe (or maybe not) it helps.

If you change the connection string in testsql.prg and remove WITHOUT OIDS
clauses in CREATE TABLE commands I think this sample must work with other
odbc drivers also.

Also, I do'nt know will mysql support CREATE temp TABLE clause. If it does
not temp can be removed also. So the TEXT command in testsql.prg may be

TEXT TO csql TEXTMERGE noshow
CREATE TABLE klient (
kood char(12),
nimi char(70),
info text);
CREATE UNIQUE INDEX klient_nimi_unique_idx ON klient(nimi);
CREATE temp TABLE dok( doktyyp char(1) );
insert into klient (kood,nimi) values ('AKU', 'Akuexpert O');
endtext

also the line in former testsql.prg

insert into testk (kood,nimi,info) values ('AKU', 'Akuexpert O','')

should me changed to
insert into testk (kood,nimi,info) values ('AKU', 'Akuexpert O','')

to avoid possible issues with character. After making changes main.exe
compiles and runs testsql.prg automatically.

I do'nt have mysql server access. Please re-confirm if you need that I must
verify this code in mysql. In this
case I must install mysql in my development computer. Or maybe there is some
mysql test server accessible over internet?

> So please be patient I'm doing everything I can

Thank you. I have one unchecked thought. If null instead of empty string is
passed as value to text type column, maybe the error does not occur.

Andrus.

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Andrus <eetasoft(at)online(dot)ee>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: Application crash after error
Date:	2005-12-02 11:36:45
Message-ID:	20051202113645.GA21663@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> > Hmmm. I get idea right now. I'll try it againist MySQL. It's ODBC is
> > open source so I can learn from it ...
> > Please could you change your example to support MySQL ODBC?
> > Maybe (or maybe not) it helps.
>
> If you change the connection string in testsql.prg and remove WITHOUT OIDS
> clauses in CREATE TABLE commands I think this sample must work with other
> odbc drivers also.

As I wrote you main.exe doesn't use testsql.prg. I changed connect string
in testsql.prg but connect string in ODBC still contains user 'postgresql'
with password you typed.
It didn't use my changes in testsql.prg.

> Thank you. I have one unchecked thought. If null instead of empty string is
> passed as value to text type column, maybe the error does not occur.

I don't think so. It's text column so it need SQLPutData. That's the
biggest problem.

Luf

P.S. I change subject as it isn't about #Deleted ...

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	pgsql-interfaces(at)postgresql(dot)org
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-05 21:28:06
Message-ID:	20051205212806.GA17690@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> We would like to upgrade the Postgres version from our current 7.3 but
> have problems with handling BLOBs via ODBC.
> We use unixODBC-2.2.11 and psqlodbc-08.01.0101.
> With postgres 7.3 lo type was mapped to SQL_C_BINARY and that's changed
> since postgres 7.4.
> Is it an ODBC or a driver issue? Are there any plans to fix the problem?

Hello,

Irine report problem with ODBC. I take deep look at it and find that
lib return base type aid instead of type aid. I'll describe it better.
We have this test suite:

CREATE DOMAIN lo as oid;
CREATE TABLE ow)(b lo);

insert one row:
INSERT INTO es=# select oid from pg_type where typname='lo'; VALUES (lo_import('file'));

we try get it throught libpq (maybe I miss some command):
- PQsetNoticeProcessor(, CC_handle_notice, qres);
- pgres = PQexec(pgconn,query);
- PQsetNoticeProcessor(pgconn, CC_handle_notice, NULL);
...
- typid = PQftype(pgres,i);
this return typid = 26 (oid) instead of 25087 (lo)

postgres=# select oid from pg_type where typname='oid';
oid
-----
26
(1 row)
postgres=# select oid from pg_type where typname='lo';
oid
-------
25087
(1 row)

Is there a way to get 25087? It seems this behaviour is changed between
PgSQL 7.3 and 7.4. It looks like backend issue. Becouse with same binary
it return different values for 7.3 and >= 7.4 (all PgSQL > 7.3 return
typid = 26 - directly tested 7.4, 8.1).

Thanks a lot for help

Luf

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	pgsql-interfaces(at)postgresql(dot)org
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 14:28:11
Message-ID:	20051206142811.GA23334@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Oh, I paste bad text and with combination of vi it gets into bad result.
I correct it now.

Hello,

Irina reports problem with ODBC. I take deep look at it and find that
libpq returns base type oid instead of type oid. I'll describe it better.
We have this test suite:

CREATE DOMAIN lo as oid;
CREATE TABLE justlo(b lo);

insert one row:
INSERT INTO justlo VALUES (lo_import('file'));

we try get it throught libpq (maybe I miss some command):
SELECT b FROM justlo;
- PQsetNoticeProcessor(pgconn, CC_handle_notice, qres);
- pgres = PQexec(pgconn,query);
- PQsetNoticeProcessor(pgconn, CC_handle_notice, NULL);
...
- typid = PQftype(pgres,i);
this returns typid = 26 (oid) instead of 25087 (lo)

postgres=# select oid from pg_type where typname='oid';
oid
-----
26
(1 row)
postgres=# select oid from pg_type where typname='lo';
oid
-------
25087
(1 row)

Is there any way to get 25087? It seems this behaviour is changed
between PgSQL 7.3 and 7.4. It looks like backend issue. Becouse it
returns different values with same binary for 7.3 and >= 7.4
(all PgSQL >= 7.4 returns typid = 26 - directly tested 7.4, 8.1).

Thanks a lot for help

Luf

From:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 15:05:01
Message-ID:	259.1133881501@sss.pgh.pa.us
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
> Irina reports problem with ODBC. I take deep look at it and find that
> libpq returns base type oid instead of type oid. I'll describe it better.

Yes, this was an intentional backend-side change. For most purposes
it's the right thing.

regards, tom lane

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 18:44:02
Message-ID:	20051206184402.GA24475@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> > Irina reports problem with ODBC. I take deep look at it and find that
> > libpq returns base type oid instead of type oid. I'll describe it better.
>
> Yes, this was an intentional backend-side change. For most purposes
> it's the right thing.

Is there any way to get type oid? Or we have to exec another query
againist system tables to get type oid. Or is there any other flag
saying we can use lo_import for the column?

I don't want to reinvent the wheel.

Thanks

Luf

From:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 19:07:13
Message-ID:	15186.1133896033@sss.pgh.pa.us
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
> I don't want to reinvent the wheel.

Why do you feel a need to distinguish the domain from its underlying
type on the client side? They're the same as regards representation
and so on.

The reason for the backend change was that client-side drivers (such as
JDBC and ODBC) want to know the underlying datatype so that they know
what representation to use etc. Distinguishing domains made their job
harder not easier.

If you want an add-on datatype that is really different from OID, then
make a real datatype (CREATE TYPE). You can still piggyback on OID as
the representation type --- steal its I/O functions and so on.

regards, tom lane

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 19:27:49
Message-ID:	20051206192749.GA24711@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> > I don't want to reinvent the wheel.
>
> Why do you feel a need to distinguish the domain from its underlying
> type on the client side? They're the same as regards representation
> and so on.

I need to determine wheter to use lo_import for large objects.
There is implementation in ODBC used type named "lo" (comapring type
oid). Type oid doesn't represent only large objects.

> what representation to use etc. Distinguishing domains made their job
> harder not easier.

I agree with you except lo implementation in ODBC ;-)

> If you want an add-on datatype that is really different from OID, then
> make a real datatype (CREATE TYPE). You can still piggyback on OID as
> the representation type --- steal its I/O functions and so on.

Does it cover lo_export which need oid as second parameter?
I'm sorry I'm new in using large objects and creating new types.

Thanks a lot

Luf

From:	Steve Howe <howe(at)carcass(dot)dhs(dot)org>
To:
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL
Date:	2005-12-06 19:29:18
Message-ID:	4395E68E.3000707@carcass.dhs.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Tom Lane wrote:

>Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
>
>
>>I don't want to reinvent the wheel.
>>
>>
>
>Why do you feel a need to distinguish the domain from its underlying
>type on the client side? They're the same as regards representation
>and so on.
>
>The reason for the backend change was that client-side drivers (such as
>JDBC and ODBC) want to know the underlying datatype so that they know
>what representation to use etc. Distinguishing domains made their job
>harder not easier.
>
>
>If you want an add-on datatype that is really different from OID, then
>make a real datatype (CREATE TYPE). You can still piggyback on OID as
>the representation type --- steal its I/O functions and so on.
>
>
A clear example situation in here is how to be able to distinguish a
large object field. The ODBC driver, for instance, uses the 'lo' type,
which is the same as an oid (Large Object).

I ran into exactly the same situation as I wrote the pgExpress driver
for Vita Voom Software: while declaring a domain looks like the clear
choice, the original type's oid would be returned by the pq_ftype()
function. So I based my solution more or less like this post by Hiroshi
Saito:

http://www.mail-archive.com/pgadmin-hackers(at)postgresql(dot)org/msg01390.html

... and asked the users to create the 'lo' type that way, which would
create a real type, just like Tom suggests.

For more details on how it was implemented on the pgExpress, please
check kits documentation:
http://www.vitavoom.com/Products/pgExpress_Driver/docs/advanced_features.html#large_objects_declaration

Best regards,
Steve Howe

From:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 19:59:40
Message-ID:	15637.1133899180@sss.pgh.pa.us
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
>> If you want an add-on datatype that is really different from OID, then
>> make a real datatype (CREATE TYPE). You can still piggyback on OID as
>> the representation type --- steal its I/O functions and so on.

> Does it cover lo_export which need oid as second parameter?

You could make an implicit cast from lo to oid ... perhaps not the other
direction, though.

regards, tom lane

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc:	pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org
Subject:	Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 21:50:22
Message-ID:	20051206215022.GB24711@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> > Does it cover lo_export which need oid as second parameter?
>
> You could make an implicit cast from lo to oid ... perhaps not the other
> direction, though.

Thank you. This way helps. I have to create implicit cast in oid->lo too
becouse there is lo_import function.
Is any reason to don't do it? I don't see this reasen as lo is same
type as oid.

CREATE FUNCTION loin (cstring) RETURNS lo AS 'oidin' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION loout (lo) RETURNS cstring AS 'oidout' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION lorecv (internal) RETURNS lo AS 'oidrecv' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION losend (lo) RETURNS bytea AS 'oidrecv' LANGUAGE internal IMMUTABLE STRICT;

CREATE TYPE lo ( INPUT = loin, OUTPUT = loout, RECEIVE = lorecv, SEND = losend, INTERNALLENGTH = 4, PASSEDBYVALUE );
CREATE CAST (lo AS oid) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (oid AS lo) WITHOUT FUNCTION AS IMPLICIT;

Thank you very much

Luf

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Irina Sourikova <irina(at)bnl(dot)gov>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-06 22:25:30
Message-ID:	20051206222530.GA25779@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

This is backend change. You have to change your type definition.

Your type is now:
CREATE DOMAIN lo AS oid;
This doesn't work since PgSQL 7.4 becouse backend returns type oid for
base type (oid not lo).

New way since PgSQL 7.4:
CREATE FUNCTION loin (cstring) RETURNS lo AS 'oidin' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION loout (lo) RETURNS cstring AS 'oidout' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION lorecv (internal) RETURNS lo AS 'oidrecv' LANGUAGE internal IMMUTABLE STRICT;
CREATE FUNCTION losend (lo) RETURNS bytea AS 'oidrecv' LANGUAGE internal IMMUTABLE STRICT;

This way works. I tested it here againist PgSQL 8.1. I looked at PgSQL 7.4
documentation and this way may be supported.
Oh, I read faq (too late) and there is described similar way.

Maybe this can be added to FAQ as this way is more complex.

Luf

From:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
To:	pgsql-odbc(at)postgresql(dot)org
Cc:	pgsql-interfaces(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-07 11:21:46
Message-ID:	874q5l40fp.fsf@meije.emic.fr
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:

> Type oid doesn't represent only large objects.

This is IMHO the original sin. oid is overloaded as both an internal
type and something the basic user has to play with.

<http://archives.postgresql.org/pgsql-jdbc/2005-07/msg00322.php>

From:	Peter Eisentraut <peter_e(at)gmx(dot)net>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-08 09:55:12
Message-ID:	200512081055.12263.peter_e@gmx.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Marc Herbert wrote:
> Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
> > Type oid doesn't represent only large objects.
>
> This is IMHO the original sin. oid is overloaded as both an internal
> type and something the basic user has to play with.

Why aren't you using bytea? Is that not supported by the ODBC driver?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

From:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-08 13:59:23
Message-ID:	871x0nr8p0.fsf@meije.emic.fr
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

> Marc Herbert wrote:
>> Ludek Finstrle <luf(at)pzkagis(dot)cz> writes:
>> > Type oid doesn't represent only large objects.
>>
>> This is IMHO the original sin. oid is overloaded as both an internal
>> type and something the basic user has to play with.
>
> Why aren't you using bytea? Is that not supported by the ODBC driver?

We are developping a middleware and are not free to choose our data
types.

As far as i know, the implementation of bytea and large objects in the
database are totally different and I suspect there are good reasons to
use either one of them, depending on the actual data and application
involved.

From:	Peter Eisentraut <peter_e(at)gmx(dot)net>
To:	pgsql-odbc(at)postgresql(dot)org
Cc:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-08 18:11:29
Message-ID:	200512081911.30002.peter_e@gmx.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Marc Herbert wrote:
> We are developping a middleware and are not free to choose our data
> types.

I was thinking the ODBC driver should provide the appropriate mapping.

> As far as i know, the implementation of bytea and large objects in
> the database are totally different and I suspect there are good
> reasons to use either one of them, depending on the actual data and
> application involved.

There is no real reason to use large objects for anything instead of
bytea.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 01:15:13
Message-ID:	20051209011513.GA8293@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Hello

> > As far as i know, the implementation of bytea and large objects in
> > the database are totally different and I suspect there are good
> > reasons to use either one of them, depending on the actual data and
> > application involved.
>
> There is no real reason to use large objects for anything instead of
> bytea.

There is a reason when you have already written application.
I don't use lo. I'm new in development of psqlODBC and one request
was: lo changed between 7.3 and 7.4
I try to solve it. You can find it in pgsql-odbc archive. It has
same subject.

I'm sorry I didn't read FAQ for psqlODBC earlier.

Regards,

Luf

From:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 10:46:01
Message-ID:	87zmnah7km.fsf@meije.emic.fr
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

> Marc Herbert wrote:
>> We are developping a middleware and are not free to choose our data
>> types.
>
> I was thinking the ODBC driver should provide the appropriate mapping.

We aim to be as transparent as possible and avoid "mappings".

<http://www.continuent.org/>

>> As far as i know, the implementation of bytea and large objects in
>> the database are totally different and I suspect there are good
>> reasons to use either one of them, depending on the actual data and
>> application involved.
>
> There is no real reason to use large objects for anything instead of
> bytea.

<http://www.postgresql.org/docs/7.4/static/jdbc-binary-data.html>
<http://jdbc.postgresql.org/documentation/head/binary-data.html>

PostgreSQL provides two distinct ways to store binary data. Binary
data can be stored in a table using the data type bytea or by using
the Large Object feature which stores the binary data in a separate
table in a special format and refers to that table by storing a value
of type oid in your table.
In order to determine which method is appropriate you need to
understand the limitations of each method....

Moreover, the respective interfaces have very different semantics
(pointer or not). This can be a reason in itself to prefer one or the
other type, whatever the underlying implementation is.

From:	Peter Eisentraut <peter_e(at)gmx(dot)net>
To:	pgsql-odbc(at)postgresql(dot)org
Cc:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 11:06:34
Message-ID:	200512091206.35456.peter_e@gmx.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Marc Herbert wrote:
> > I was thinking the ODBC driver should provide the appropriate
> > mapping.
>
> We aim to be as transparent as possible and avoid "mappings".
> <http://www.continuent.org/>

So continuent is now writing an ODBC driver for PostgreSQL, or what are
you trying to say?

> Moreover, the respective interfaces have very different semantics
> (pointer or not). This can be a reason in itself to prefer one or the
> other type, whatever the underlying implementation is.

This is handwaving. I know the section in the documentation; I wrote
it. But what actual reasons do you have for using one or the other?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

From:	Peter Eisentraut <peter_e(at)gmx(dot)net>
To:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 11:08:44
Message-ID:	200512091208.44967.peter_e@gmx.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Ludek Finstrle wrote:
> There is a reason when you have already written application.
> I don't use lo. I'm new in development of psqlODBC and one request
> was: lo changed between 7.3 and 7.4

I'm certainly not defending incompatible changes that break
applications. I'm just wondering whether these problems can be avoided
altogether in the future.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

From:	Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
To:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 11:40:15
Message-ID:	87r78mh528.fsf@meije.emic.fr
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

>> <http://www.continuent.org/>
>
> So continuent is now writing an ODBC driver for PostgreSQL, or what are
> you trying to say?

No more than what you'll find at the link above, if you are
interested. And you don't have to; this is becoming more and more
irrelevant to this list or to this thread.

>> Moreover, the respective interfaces have very different semantics
>> (pointer or not). This can be a reason in itself to prefer one or the
>> other type, whatever the underlying implementation is.
>
> This is handwaving.

Sorry, I don't get this.

> I know the section in the documentation; I wrote it.

Then thanks in advance for fixing it, putting it in line with what you
said above.

PS: unless stated otherwise, I read the forums where I post. Thanks in
advance for not sending me copies.

From:	Ludek Finstrle <luf(at)pzkagis(dot)cz>
To:	Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc:	pgsql-odbc(at)postgresql(dot)org
Subject:	Re: BLOB handling compatibility with PostgreSQL > 7.4
Date:	2005-12-09 14:10:43
Message-ID:	20051209141043.GB13154@soptik.pzkagis.cz
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-interfaces pgsql-odbc

> > There is a reason when you have already written application.
> > I don't use lo. I'm new in development of psqlODBC and one request
> > was: lo changed between 7.3 and 7.4
>
> I'm certainly not defending incompatible changes that break
> applications. I'm just wondering whether these problems can be avoided
> altogether in the future.

I think ODBC driver is doing some mapping with lo. But the driver have
to determine if it is LO column or not (when user choose to use lo).

Luf