Обсуждение: RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
> -----Original Message----- > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp] > Sent: 25 January 2001 10:15 > To: Dave Page > Cc: Bruce Momjian; 'pgsql-odbc@postgresql.org' > Subject: Re: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large > Querys & Rows > > It's not me who would send such queries. For exmaple, intelligent > DAO/RDO/ADO could see that a long or an oj query is allowed and > send such queries automatically in some cases though I don't know > if it would really occur or not. 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! Regards, Dave.
> 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
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > 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. > I strongly object. Postgres ODBC driver has supported all the way back to version 6.2( or 6.0 according to a person's opinion). Why could we easily break the backward compatibility without any consensus ? I also object to centralize the version info. It is preferable that client apps and servers are relatively indepedent as much as possible. It seems very natural that client apps and the server have separate versioning policies. Do we always have to wait for the all-in-one release to get improved client apps ? Regrads, Hiroshi Inoue
What exactly do you mean by centralize the version info? Do you mean having the ODBC driver version match the Postgres DB version? If so, I do agree in doing that... to a degree. I say we only match major versions where there are added features. As an example, 7.0 has many feature additions over 6.5. Once the driver supports all the functionality of 7.0, it should be moved to version 7.0. Then, if a patch or something is added to the ODBC to require it being upped a version, we should use very minor increments, something like a precision of 4 or 5. (A patched 7.0 driver would be incremented to 7.0.0.0.1) That way, we know a driver version as 7.0 supports all functionality from 7.0 servers and back. Adam Lang Systems Engineer Rutgers Casualty Insurance Company http://www.rutgersinsurance.com ----- Original Message ----- From: "Hiroshi Inoue" <Inoue@tpf.co.jp> To: "Dave Page" <dpage@vale-housing.co.uk>; "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>; <pgsql-odbc@postgresql.org> Sent: Thursday, January 25, 2001 11:28 AM Subject: RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows <snip> > I also object to centralize the version info. It is preferable that client > apps and servers are relatively indepedent as much as possible. > It seems very natural that client apps and the server have separate > versioning policies. Do we always have to wait for the all-in-one > release to get improved client apps ? > > Regrads, > Hiroshi Inoue
Adam Lang wrote: > > What exactly do you mean by centralize the version info? Do you mean having > the ODBC driver version match the Postgres DB version? > Yes. IIRC, there was a discussion about the autogeneration of the version numbers from PostgreSQL source configuration. I object to the idea. > If so, I do agree in doing that... to a degree. I say we only match major > versions where there are added features. As an example, 7.0 has many > feature additions over 6.5. Once the driver supports all the functionality > of 7.0, it should be moved to version 7.0. Then, if a patch or something is > added to the ODBC to require it being upped a version, we should use very > minor increments, something like a precision of 4 or 5. (A patched 7.0 > driver would be incremented to 7.0.0.0.1) That way, we know a driver version > as 7.0 supports all functionality from 7.0 servers and back. Agreed. Regards, Hiroshi Inoue > > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company > http://www.rutgersinsurance.com > ----- Original Message ----- > From: "Hiroshi Inoue" <Inoue@tpf.co.jp> > To: "Dave Page" <dpage@vale-housing.co.uk>; "Bruce Momjian" > <pgman@candle.pha.pa.us> > Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>; > <pgsql-odbc@postgresql.org> > Sent: Thursday, January 25, 2001 11:28 AM > Subject: RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows > > <snip> > > I also object to centralize the version info. It is preferable that client > > apps and servers are relatively indepedent as much as possible. > > It seems very natural that client apps and the server have separate > > versioning policies. Do we always have to wait for the all-in-one > > release to get improved client apps ? > > > > Regrads, > > Hiroshi Inoue