From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200101251347.IAA10548@candle.pha.pa.us>
Subject: Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
In-Reply-To: <8568FC767B4AD311AC33006097BCD3D61A2923@woody.vale-housing.co.uk>
	"from Dave Page at Jan 25, 2001 10:40:45 am"
To: Dave Page <dpage@vale-housing.co.uk>
Date: Thu, 25 Jan 2001 08:47:20 -0500 (EST)
CC: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>,
	"'pgsql-odbc@postgresql.org'" <pgsql-odbc@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

> Yes, that could happen, though in reality I suspect it proably wouldn't as
> (in my experience - I may be wrong) those technologies do little more than
> putting SELECT * FROM in front of a given table name and generating query
> based updates.
> 
> I suspect that more problems may be caused for apps like MS Query or Seagate
> Crystal Reports which might attempt to use outer joins on an older database
> (actually Query just enables/disables the relevant join options). As far as
> I can tell, the driver doesn't check the backend version (despite returning
> the DBMS version which is currently hardcoded), so we'd either need to add a
> 7.1 protocol option (not nice as it isn't really a different protocol) or do
> a SELECT VERSION() on connect to get the exact version string and figure out
> what is/isn't possible from that.
> 
> I'll look into it but I'm on the wrong end of the learning curve here!

We usually are more concerned about old libraries talking to new
servers.  New libraries talking to old servers are not needed as much.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026