Thread: more odbc patches
hi, there! there is one problem with Zoltan patches commited into the tree: if we set autocommit off and issued COMMIT (or ROLLBACK) on a connection new transaction is not started attached patch should solve this problem (it mostly contains old cruft removal -- i can send minimal patch if necessary) /fjoe
hi, there! On Thu, 14 Dec 2000, Max Khon wrote: > there is one problem with Zoltan patches commited into the tree: > if we set autocommit off and issued COMMIT (or ROLLBACK) on a connection > new transaction is not started > > attached patch should solve this problem (it mostly contains old cruft > removal -- i can send minimal patch if necessary) sorry, new patch (without compilation warnings) /fjoe
Are new odbc installs (postdrv.exe) created when there are patches? Aka. we can uninstall the old driver, download the new one and install it? Or is it up to us to compile a new driver? Adam Lang Systems Engineer Rutgers Casualty Insurance Company http://www.rutgersinsurance.com ----- Original Message ----- From: "Max Khon" <fjoe@iclub.nsu.ru> To: <pgsql-interfaces@postgresql.org> Sent: Thursday, December 14, 2000 8:58 AM Subject: [INTERFACES] more odbc patches > hi, there! > > there is one problem with Zoltan patches commited into the tree: > if we set autocommit off and issued COMMIT (or ROLLBACK) on a connection > new transaction is not started > > attached patch should solve this problem (it mostly contains old cruft > removal -- i can send minimal patch if necessary) > > /fjoe >
> Are new odbc installs (postdrv.exe) created when there are patches? Aka. we
> can uninstall the old driver, download the new one and install it? Or is it
> up to us to compile a new driver?
We've been getting some great patches for ODBC recently, but can always
use a bit more help for posting compiled versions, documentation, etc
etc.
The server at ftp.postgresql.org is available to anyone wanting to post
binary packages.
- Thomas
I'd love to... but unless I can compile it for you in VB, no luck. Adam Lang Systems Engineer Rutgers Casualty Insurance Company http://www.rutgersinsurance.com ----- Original Message ----- From: "Thomas Lockhart" <lockhart@alumni.caltech.edu> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: <pgsql-interfaces@postgresql.org> Sent: Thursday, December 14, 2000 11:08 AM Subject: Re: [INTERFACES] more odbc patches > > Are new odbc installs (postdrv.exe) created when there are patches? Aka. we > > can uninstall the old driver, download the new one and install it? Or is it > > up to us to compile a new driver? > > We've been getting some great patches for ODBC recently, but can always > use a bit more help for posting compiled versions, documentation, etc > etc. > > The server at ftp.postgresql.org is available to anyone wanting to post > binary packages. > > - Thomas
On Thu, 14 Dec 2000, Adam Lang wrote: > I'd love to... but unless I can compile it for you in VB, no luck. I'm almost sure you can. Good luck and thanks! Zoltan
I can compile the ODBC driver with VB?!?!? Adam Lang Systems Engineer Rutgers Casualty Insurance Company http://www.rutgersinsurance.com ----- Original Message ----- From: "Kovacs Zoltan Sandor" <tip@pc10.radnoti-szeged.sulinet.hu> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: <pgsql-interfaces@postgresql.org> Sent: Thursday, December 14, 2000 11:07 AM Subject: Re: [INTERFACES] more odbc patches > On Thu, 14 Dec 2000, Adam Lang wrote: > > > I'd love to... but unless I can compile it for you in VB, no luck. > I'm almost sure you can. Good luck and thanks! Zoltan
On Thu, 14 Dec 2000, Adam Lang wrote: > I can compile the ODBC driver with VB?!?!? Oh no! I'm sorry! I read VB as VC... of course, you can't... :-( Z.
hehe... you started getting me excited for a moment. :) Adam Lang Systems Engineer Rutgers Casualty Insurance Company http://www.rutgersinsurance.com ----- Original Message ----- From: "Kovacs Zoltan Sandor" <tip@pc10.radnoti-szeged.sulinet.hu> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: <pgsql-interfaces@postgresql.org> Sent: Thursday, December 14, 2000 11:17 AM Subject: Re: [INTERFACES] more odbc patches > On Thu, 14 Dec 2000, Adam Lang wrote: > > > I can compile the ODBC driver with VB?!?!? > Oh no! I'm sorry! I read VB as VC... of course, you can't... :-( Z.
Applied. Thanks. > hi, there! > > On Thu, 14 Dec 2000, Max Khon wrote: > > > there is one problem with Zoltan patches commited into the tree: > > if we set autocommit off and issued COMMIT (or ROLLBACK) on a connection > > new transaction is not started > > > > attached patch should solve this problem (it mostly contains old cruft > > removal -- i can send minimal patch if necessary) > > sorry, new patch (without compilation warnings) > > /fjoe Content-Description: [ Attachment, skipping... ] -- 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, Pennsylvania19026
hi, there! how about this? --- cut here ---
I'm having trouble with connecting to db. I created user and password by
creatuser and pg_passwd, and have line in my pg_hba.conf
#####
local all password passwd
host all 127.0.0.1 255.255.255.255 password passwd
#####
passwd is file create to have password.
now when i try to connect to db by
#####
DriverManager.getConnection("jdbc:postgresql:test",user,pass);
#####
I get the following error messg,
#####
The backend has broken the connection. Possibly the action you have
attempted has caused it to close.
#####
i don't know what is causing to get this error anyone have any idea?
katsu
Katsuyuki Tanaka <katsut@cse.unsw.EDU.AU> writes:
> I get the following error messg,
> #####
> The backend has broken the connection. Possibly the action you have
> attempted has caused it to close.
> #####
That's a pretty content-free message, isn't it :-(
There might be more information in the postmaster log. Make sure
you are saving a postmaster log (postmaster should be started without
-S switch, and with stdout and stderr routed to some logfile), and
then see what gets appended to the log when you try to connect.
regards, tom lane
Can someone comment on this? > hi, there! > > how about this? > > --- cut here --- > >From cs@plesk.com Sat Dec 16 15:08:40 2000 > Date: Thu, 14 Dec 2000 17:00:43 +0600 (NOVT) > From: Constantin S. Svintsoff <cs@plesk.com> > To: fjoe@iclub.nsu.ru > Subject: Bug in SQLForeignKeys() > > > Query used for checking foreign key triggers > returns too many results when there're more than one foreign > key in a table. It happens because only table's oid is used to > link between pg_trigger with INSERT check and pg_trigger with > UPDATE/DELETE check. > > I think there should be enough to add following conditions > into WHERE clause of that query: > AND pt.tgconstrname = pg_trigger.tgconstrname > AND pt.tgconstrname = pg_trigger_1.tgconstrname > > /Constantin > --- cut here --- > > /fjoe > > -- 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, Pennsylvania19026
hi, there! On Mon, 22 Jan 2001, Bruce Momjian wrote: > Can someone comment on this? I have got more comments from Constantin: current implementation will fail (return too many rows) if one table has two foreign keys, e.g.: CREATE TABLE prim(i integer PRIMARY KEY); CREATE TABLE f(i integer REFERENCES prim, j integer REFERENCES prim); > > how about this? > > > > --- cut here --- > > >From cs@plesk.com Sat Dec 16 15:08:40 2000 > > Date: Thu, 14 Dec 2000 17:00:43 +0600 (NOVT) > > From: Constantin S. Svintsoff <cs@plesk.com> > > To: fjoe@iclub.nsu.ru > > Subject: Bug in SQLForeignKeys() > > > > > > Query used for checking foreign key triggers > > returns too many results when there're more than one foreign > > key in a table. It happens because only table's oid is used to > > link between pg_trigger with INSERT check and pg_trigger with > > UPDATE/DELETE check. > > > > I think there should be enough to add following conditions > > into WHERE clause of that query: > > AND pt.tgconstrname = pg_trigger.tgconstrname > > AND pt.tgconstrname = pg_trigger_1.tgconstrname > > > > /Constantin > > --- cut here --- /fjoe
I don't get it. Does this mean the ODBC driver is checking referential integrity before it passes things to the backend server? Seems kind of pointless to me. I thought the ODBC driver just passes through RI errors generated by the backend. -Cedar On Tue, 23 Jan 2001, Max Khon wrote: > hi, there! > > On Mon, 22 Jan 2001, Bruce Momjian wrote: > > > Can someone comment on this? > > I have got more comments from Constantin: current implementation will fail > (return too many rows) if one table has two foreign keys, e.g.: > CREATE TABLE prim(i integer PRIMARY KEY); > CREATE TABLE f(i integer REFERENCES prim, j integer REFERENCES prim);
hi, there! On Tue, 23 Jan 2001, Cedar Cox wrote: > I don't get it. Does this mean the ODBC driver is checking referential > integrity before it passes things to the backend server? Seems kind of > pointless to me. I thought the ODBC driver just passes through RI errors > generated by the backend. we talk about SQLForeignKeys functionality :) it has nothing to do with RI errors reporting > On Tue, 23 Jan 2001, Max Khon wrote: > > > hi, there! > > > > On Mon, 22 Jan 2001, Bruce Momjian wrote: > > > > > Can someone comment on this? > > > > I have got more comments from Constantin: current implementation will fail > > (return too many rows) if one table has two foreign keys, e.g.: > > CREATE TABLE prim(i integer PRIMARY KEY); > > CREATE TABLE f(i integer REFERENCES prim, j integer REFERENCES prim); /fjoe
I have applied the following diff to ODBC to fix the problem, as Constantin suggested. Would some ODBC folks please test this and make sure it works? > hi, there! > > how about this? > > --- cut here --- > >From cs@plesk.com Sat Dec 16 15:08:40 2000 > Date: Thu, 14 Dec 2000 17:00:43 +0600 (NOVT) > From: Constantin S. Svintsoff <cs@plesk.com> > To: fjoe@iclub.nsu.ru > Subject: Bug in SQLForeignKeys() > > > Query used for checking foreign key triggers > returns too many results when there're more than one foreign > key in a table. It happens because only table's oid is used to > link between pg_trigger with INSERT check and pg_trigger with > UPDATE/DELETE check. > > I think there should be enough to add following conditions > into WHERE clause of that query: > AND pt.tgconstrname = pg_trigger.tgconstrname > AND pt.tgconstrname = pg_trigger_1.tgconstrname > > /Constantin > --- cut here --- > > /fjoe > > -- 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 ? config.log ? config.cache ? config.status ? GNUmakefile ? doc/TODO.detail/ProposedTools.doc ? doc/TODO.detail/RDBATools.xls ? src/Makefile.custom ? src/GNUmakefile ? src/Makefile.global ? src/log ? src/crtags ? src/backend/postgres ? src/backend/catalog/global.description ? src/backend/catalog/global.bki ? src/backend/catalog/template1.bki ? src/backend/catalog/template1.description ? src/backend/port/Makefile ? src/bin/initdb/initdb ? src/bin/initlocation/initlocation ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_restore ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_id/pg_id ? src/bin/pg_passwd/pg_passwd ? src/bin/pgaccess/pgaccess ? src/bin/pgtclsh/Makefile.tkdefs ? src/bin/pgtclsh/Makefile.tcldefs ? src/bin/pgtclsh/pgtclsh ? src/bin/pgtclsh/pgtksh ? src/bin/psql/psql ? src/bin/scripts/createlang ? src/include/config.h ? src/include/stamp-h ? src/interfaces/ecpg/lib/libecpg.so.3.2.0 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpgeasy/libpgeasy.so.2.1 ? src/interfaces/libpgtcl/libpgtcl.so.2.1 ? src/interfaces/libpq/libpq.so.2.1 ? src/interfaces/perl5/blib ? src/interfaces/perl5/Makefile ? src/interfaces/perl5/pm_to_blib ? src/interfaces/perl5/Pg.c ? src/interfaces/perl5/Pg.bs ? src/pl/plperl/blib ? src/pl/plperl/Makefile ? src/pl/plperl/pm_to_blib ? src/pl/plperl/SPI.c ? src/pl/plperl/plperl.bs ? src/pl/plpgsql/src/libplpgsql.so.1.0 ? src/pl/tcl/Makefile.tcldefs Index: src/interfaces/odbc/info.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/odbc/info.c,v retrieving revision 1.26 diff -c -r1.26 info.c *** src/interfaces/odbc/info.c 2000/12/11 18:51:25 1.26 --- src/interfaces/odbc/info.c 2001/01/23 20:24:01 *************** *** 2368,2374 **** "AND (pg_proc.proname LIKE '%%upd') " "AND (pg_proc_1.proname LIKE '%%del') " "AND (pg_trigger.tgrelid=pt.tgconstrrelid) " ! "AND (pg_trigger_1.tgrelid = pt.tgconstrrelid))", fk_table_needed); result = SQLExecDirect(htbl_stmt, tables_query, strlen(tables_query)); --- 2368,2376 ---- "AND (pg_proc.proname LIKE '%%upd') " "AND (pg_proc_1.proname LIKE '%%del') " "AND (pg_trigger.tgrelid=pt.tgconstrrelid) " ! "AND (pg_trigger.tgconstrname=pt.tgconstrname) " ! "AND (pg_trigger_1.tgrelid=pt.tgconstrrelid) ", ! "AND (pg_trigger_1.tgconstrname=pt.tgconstrname))", fk_table_needed); result = SQLExecDirect(htbl_stmt, tables_query, strlen(tables_query)); Index: src/interfaces/odbc/pgtypes.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/odbc/pgtypes.c,v retrieving revision 1.15 diff -c -r1.15 pgtypes.c *** src/interfaces/odbc/pgtypes.c 2000/05/27 03:35:14 1.15 --- src/interfaces/odbc/pgtypes.c 2001/01/23 20:24:01 *************** *** 217,223 **** case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! case PG_TYPE_INT8: return SQL_BIGINT; case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL; --- 217,225 ---- case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! /* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ ! case PG_TYPE_INT8: return SQL_CHAR; ! case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL;
Sorry, here is the correct patch. > hi, there! > > how about this? > > --- cut here --- > >From cs@plesk.com Sat Dec 16 15:08:40 2000 > Date: Thu, 14 Dec 2000 17:00:43 +0600 (NOVT) > From: Constantin S. Svintsoff <cs@plesk.com> > To: fjoe@iclub.nsu.ru > Subject: Bug in SQLForeignKeys() > > > Query used for checking foreign key triggers > returns too many results when there're more than one foreign > key in a table. It happens because only table's oid is used to > link between pg_trigger with INSERT check and pg_trigger with > UPDATE/DELETE check. > > I think there should be enough to add following conditions > into WHERE clause of that query: > AND pt.tgconstrname = pg_trigger.tgconstrname > AND pt.tgconstrname = pg_trigger_1.tgconstrname > > /Constantin > --- cut here --- > > /fjoe > > -- 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 ? config.log ? config.cache ? config.status ? GNUmakefile ? doc/TODO.detail/ProposedTools.doc ? doc/TODO.detail/RDBATools.xls ? src/Makefile.custom ? src/GNUmakefile ? src/Makefile.global ? src/log ? src/crtags ? src/backend/postgres ? src/backend/catalog/global.description ? src/backend/catalog/global.bki ? src/backend/catalog/template1.bki ? src/backend/catalog/template1.description ? src/backend/port/Makefile ? src/bin/initdb/initdb ? src/bin/initlocation/initlocation ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_restore ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_id/pg_id ? src/bin/pg_passwd/pg_passwd ? src/bin/pgaccess/pgaccess ? src/bin/pgtclsh/Makefile.tkdefs ? src/bin/pgtclsh/Makefile.tcldefs ? src/bin/pgtclsh/pgtclsh ? src/bin/pgtclsh/pgtksh ? src/bin/psql/psql ? src/bin/scripts/createlang ? src/include/config.h ? src/include/stamp-h ? src/interfaces/ecpg/lib/libecpg.so.3.2.0 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpgeasy/libpgeasy.so.2.1 ? src/interfaces/libpgtcl/libpgtcl.so.2.1 ? src/interfaces/libpq/libpq.so.2.1 ? src/interfaces/perl5/blib ? src/interfaces/perl5/Makefile ? src/interfaces/perl5/pm_to_blib ? src/interfaces/perl5/Pg.c ? src/interfaces/perl5/Pg.bs ? src/pl/plperl/blib ? src/pl/plperl/Makefile ? src/pl/plperl/pm_to_blib ? src/pl/plperl/SPI.c ? src/pl/plperl/plperl.bs ? src/pl/plpgsql/src/libplpgsql.so.1.0 ? src/pl/tcl/Makefile.tcldefs Index: src/interfaces/odbc/info.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/odbc/info.c,v retrieving revision 1.26 diff -c -r1.26 info.c *** src/interfaces/odbc/info.c 2000/12/11 18:51:25 1.26 --- src/interfaces/odbc/info.c 2001/01/23 20:34:37 *************** *** 2368,2374 **** "AND (pg_proc.proname LIKE '%%upd') " "AND (pg_proc_1.proname LIKE '%%del') " "AND (pg_trigger.tgrelid=pt.tgconstrrelid) " ! "AND (pg_trigger_1.tgrelid = pt.tgconstrrelid))", fk_table_needed); result = SQLExecDirect(htbl_stmt, tables_query, strlen(tables_query)); --- 2368,2376 ---- "AND (pg_proc.proname LIKE '%%upd') " "AND (pg_proc_1.proname LIKE '%%del') " "AND (pg_trigger.tgrelid=pt.tgconstrrelid) " ! "AND (pg_trigger.tgconstrname=pt.tgconstrname) " ! "AND (pg_trigger_1.tgrelid=pt.tgconstrrelid) " ! "AND (pg_trigger_1.tgconstrname=pt.tgconstrname))", fk_table_needed); result = SQLExecDirect(htbl_stmt, tables_query, strlen(tables_query)); Index: src/interfaces/odbc/pgtypes.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/odbc/pgtypes.c,v retrieving revision 1.15 diff -c -r1.15 pgtypes.c *** src/interfaces/odbc/pgtypes.c 2000/05/27 03:35:14 1.15 --- src/interfaces/odbc/pgtypes.c 2001/01/23 20:34:38 *************** *** 217,223 **** case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! case PG_TYPE_INT8: return SQL_BIGINT; case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL; --- 217,225 ---- case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! /* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ ! case PG_TYPE_INT8: return SQL_CHAR; ! case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL;