pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedmore odbc patches
18+ messages / 6 participants
[nested] [flat]
* more odbc patches
@ 2000-12-14 13:58 Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 2 replies; 18+ messages in thread
From: Max Khon @ 2000-12-14 13:58 UTC (permalink / raw)
To: pgsql-interfaces
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
Attachments:
odbc-patch (text/plain, 3.2K) download
? libpsqlodbc.so.0
? foo
Index: options.c
===================================================================
RCS file: /opt/cvs/postgresql.org/pgsql/src/interfaces/odbc/options.c,v
retrieving revision 1.16
diff -u -r1.16 options.c
--- options.c 2000/10/28 15:10:36 1.16
+++ options.c 2000/12/14 13:49:30
@@ -314,32 +314,18 @@
case SQL_AUTOCOMMIT:
- /* Since we are almost always in a transaction, this is now ok.
- Even if we were, the logic will handle it by sending a commit
- after the statement.
-
if (CC_is_in_trans(conn)) {
- conn->errormsg = "Cannot switch commit mode while a transaction is in progres";
+ conn->errormsg = "Cannot switch commit mode while a transaction is in progress";
conn->errornumber = CONN_TRANSACT_IN_PROGRES;
CC_log_error(func, "", conn);
return SQL_ERROR;
}
- */
mylog("SQLSetConnectOption: AUTOCOMMIT: transact_status=%d, vparam=%d\n", conn->transact_status, vParam);
switch(vParam) {
case SQL_AUTOCOMMIT_OFF:
CC_set_autocommit_off(conn);
- /* The following two lines are new.
- With this modification the SELECT statements
- are also included in the transactions.
- Error handling should be written,
- this is missing yet, see
- SC_execute in statement.c for details. Zoltan
- */
- CC_send_query(conn,"BEGIN",NULL);
- CC_set_in_trans(conn);
break;
case SQL_AUTOCOMMIT_ON:
Index: statement.c
===================================================================
RCS file: /opt/cvs/postgresql.org/pgsql/src/interfaces/odbc/statement.c,v
retrieving revision 1.18
diff -u -r1.18 statement.c
--- statement.c 2000/10/25 14:15:49 1.18
+++ statement.c 2000/12/14 13:49:30
@@ -750,12 +750,12 @@
starting a transaction first.
A transaction should be begun if and only if
- we use declare/fetch and the statement is SELECT.
+ we use declare/fetch and the statement is SELECT
+ or we are not in autocommit state
We assume that the Postgres backend has an autocommit
feature as default. (Zoltan Kovacs, 04/26/2000)
*/
- // if ( ! self->internal && ! CC_is_in_trans(conn) && (globals.use_declarefetch || STMT_UPDATE(self))) {
- if ( ! self->internal && ! CC_is_in_trans(conn) && globals.use_declarefetch && self->statement_type == STMT_TYPE_SELECT) {
+ if ( ! self->internal && ! CC_is_in_trans(conn) && (globals.use_declarefetch && self->statement_type == STMT_TYPE_SELECT || ! CC_is_in_autocommit(conn))) {
mylog(" about to begin a transaction on statement = %u\n", self);
res = CC_send_query(conn, "BEGIN", NULL);
@@ -831,16 +831,9 @@
mylog(" it's NOT a select statement: stmt=%u\n", self);
self->result = CC_send_query(conn, self->stmt_with_params, NULL);
- /* If we are in autocommit, we must send the commit. */
- /* No, we shouldn't. Postgres backend does the
+ /* We shouldn't send COMMIT. Postgres backend does the
autocommit if neccessary. (Zoltan, 04/26/2000)
*/
-/* if ( ! self->internal && CC_is_in_autocommit(conn) && STMT_UPDATE(self)) {
- res = CC_send_query(conn, "COMMIT", NULL);
- QR_Destructor(res);
- CC_set_no_trans(conn);
- }*/
-
}
conn->status = oldstatus;
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2000-12-14 14:04 ` Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 18+ messages in thread
From: Max Khon @ 2000-12-14 14:04 UTC (permalink / raw)
To: pgsql-interfaces
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
Attachments:
odbc-patch2 (text/plain, 3.2K) download
? libpsqlodbc.so.0
? foo
Index: options.c
===================================================================
RCS file: /opt/cvs/postgresql.org/pgsql/src/interfaces/odbc/options.c,v
retrieving revision 1.16
diff -u -r1.16 options.c
--- options.c 2000/10/28 15:10:36 1.16
+++ options.c 2000/12/14 14:02:53
@@ -314,32 +314,18 @@
case SQL_AUTOCOMMIT:
- /* Since we are almost always in a transaction, this is now ok.
- Even if we were, the logic will handle it by sending a commit
- after the statement.
-
if (CC_is_in_trans(conn)) {
- conn->errormsg = "Cannot switch commit mode while a transaction is in progres";
+ conn->errormsg = "Cannot switch commit mode while a transaction is in progress";
conn->errornumber = CONN_TRANSACT_IN_PROGRES;
CC_log_error(func, "", conn);
return SQL_ERROR;
}
- */
mylog("SQLSetConnectOption: AUTOCOMMIT: transact_status=%d, vparam=%d\n", conn->transact_status, vParam);
switch(vParam) {
case SQL_AUTOCOMMIT_OFF:
CC_set_autocommit_off(conn);
- /* The following two lines are new.
- With this modification the SELECT statements
- are also included in the transactions.
- Error handling should be written,
- this is missing yet, see
- SC_execute in statement.c for details. Zoltan
- */
- CC_send_query(conn,"BEGIN",NULL);
- CC_set_in_trans(conn);
break;
case SQL_AUTOCOMMIT_ON:
Index: statement.c
===================================================================
RCS file: /opt/cvs/postgresql.org/pgsql/src/interfaces/odbc/statement.c,v
retrieving revision 1.18
diff -u -r1.18 statement.c
--- statement.c 2000/10/25 14:15:49 1.18
+++ statement.c 2000/12/14 14:02:53
@@ -750,12 +750,12 @@
starting a transaction first.
A transaction should be begun if and only if
- we use declare/fetch and the statement is SELECT.
+ we use declare/fetch and the statement is SELECT
+ or we are not in autocommit state
We assume that the Postgres backend has an autocommit
feature as default. (Zoltan Kovacs, 04/26/2000)
*/
- // if ( ! self->internal && ! CC_is_in_trans(conn) && (globals.use_declarefetch || STMT_UPDATE(self))) {
- if ( ! self->internal && ! CC_is_in_trans(conn) && globals.use_declarefetch && self->statement_type == STMT_TYPE_SELECT) {
+ if ( ! self->internal && ! CC_is_in_trans(conn) && ((globals.use_declarefetch && self->statement_type == STMT_TYPE_SELECT) || ! CC_is_in_autocommit(conn))) {
mylog(" about to begin a transaction on statement = %u\n", self);
res = CC_send_query(conn, "BEGIN", NULL);
@@ -831,16 +831,9 @@
mylog(" it's NOT a select statement: stmt=%u\n", self);
self->result = CC_send_query(conn, self->stmt_with_params, NULL);
- /* If we are in autocommit, we must send the commit. */
- /* No, we shouldn't. Postgres backend does the
+ /* We shouldn't send COMMIT. Postgres backend does the
autocommit if neccessary. (Zoltan, 04/26/2000)
*/
-/* if ( ! self->internal && CC_is_in_autocommit(conn) && STMT_UPDATE(self)) {
- res = CC_send_query(conn, "COMMIT", NULL);
- QR_Destructor(res);
- CC_set_no_trans(conn);
- }*/
-
}
conn->status = oldstatus;
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2000-12-15 19:12 ` Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
0 siblings, 1 reply; 18+ messages in thread
From: Bruce Momjian @ 2000-12-15 19:12 UTC (permalink / raw)
To: Max Khon <fjoe@iclub.nsu.ru>; +Cc: pgsql-interfaces
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, Pennsylvania 19026
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
@ 2000-12-16 09:10 ` Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 04:45 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 20:32 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 20:35 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 3 replies; 18+ messages in thread
From: Max Khon @ 2000-12-16 09:10 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2001-01-23 04:45 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 09:12 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2 siblings, 1 reply; 18+ messages in thread
From: Bruce Momjian @ 2001-01-23 04:45 UTC (permalink / raw)
To: Max Khon <fjoe@iclub.nsu.ru>; +Cc: pgsql-interfaces
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, Pennsylvania 19026
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 04:45 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
@ 2001-01-23 09:12 ` Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 11:15 ` Re: Re: more odbc patches Cedar Cox <cedarc@visionforisrael.com>
0 siblings, 1 reply; 18+ messages in thread
From: Max Khon @ 2001-01-23 09:12 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 04:45 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 09:12 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2001-01-23 11:15 ` Cedar Cox <cedarc@visionforisrael.com>
2001-01-23 18:05 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
0 siblings, 1 reply; 18+ messages in thread
From: Cedar Cox @ 2001-01-23 11:15 UTC (permalink / raw)
To: pgsql-odbc@postgresql.org; +Cc: Max Khon <fjoe@iclub.nsu.ru>; Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-interfaces
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);
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 04:45 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 09:12 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 11:15 ` Re: Re: more odbc patches Cedar Cox <cedarc@visionforisrael.com>
@ 2001-01-23 18:05 ` Max Khon <fjoe@iclub.nsu.ru>
0 siblings, 0 replies; 18+ messages in thread
From: Max Khon @ 2001-01-23 18:05 UTC (permalink / raw)
To: Cedar Cox <cedarc@visionforisrael.com>; +Cc: pgsql-odbc@postgresql.org, Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2001-01-23 20:32 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-24 09:52 ` Re: Re: [INTERFACES] Re: more odbc patches Cedar Cox <cedarc@visionforisrael.com>
2 siblings, 1 reply; 18+ messages in thread
From: Bruce Momjian @ 2001-01-23 20:32 UTC (permalink / raw)
To: Max Khon <fjoe@iclub.nsu.ru>; +Cc: PostgreSQL odbc list <pgsql-odbc@postgresql.org>; PostgreSQL-patches <pgsql-patches@postgresql.org>
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
Attachments:
/bjm/diff (text/plain, 3.4K) download
? 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;
* Re: Re: [INTERFACES] Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 20:32 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
@ 2001-01-24 09:52 ` Cedar Cox <cedarc@visionforisrael.com>
0 siblings, 0 replies; 18+ messages in thread
From: Cedar Cox @ 2001-01-24 09:52 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Max Khon <fjoe@iclub.nsu.ru>; PostgreSQL odbc list <pgsql-odbc@postgresql.org>
On Tue, 23 Jan 2001, Bruce Momjian wrote:
> 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?
I'd be happy to, but I need a little help :) First of all, do all these
changes I keep seeing have to do with both unix ODBC and windows ODBC? I
don't have a compiler in windows. Is anyone posting compiled versions for
people like me to try out? Lastly, what is it that I'm checking? I
obviously need to learn something about SQLForeignKeys. As far as I knew,
anything that had to do with foreign keys was RI. Simple explanation?, or
link to some reading material?
Thanks,
-Cedar
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Re: Re: more odbc patches Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Re: Re: more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2001-01-23 20:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 0 replies; 18+ messages in thread
From: Bruce Momjian @ 2001-01-23 20:35 UTC (permalink / raw)
To: Max Khon <fjoe@iclub.nsu.ru>; +Cc: pgsql-interfaces
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
Attachments:
/bjm/diff (text/plain, 3.4K) download
? 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;
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
@ 2000-12-14 14:15 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 1 reply; 18+ messages in thread
From: Adam Lang @ 2000-12-14 14:15 UTC (permalink / raw)
To: pgsql-interfaces
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
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
@ 2000-12-14 16:08 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Lockhart @ 2000-12-14 16:08 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
@ 2000-12-14 16:02 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:07 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
0 siblings, 1 reply; 18+ messages in thread
From: Adam Lang @ 2000-12-14 16:02 UTC (permalink / raw)
To: ; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
@ 2000-12-14 16:07 ` Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 16:13 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 18+ messages in thread
From: Kovacs Zoltan Sandor @ 2000-12-14 16:07 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:07 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
@ 2000-12-14 16:13 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:17 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
0 siblings, 1 reply; 18+ messages in thread
From: Adam Lang @ 2000-12-14 16:13 UTC (permalink / raw)
To: ; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:07 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 16:13 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
@ 2000-12-14 16:17 ` Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 18:17 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 18+ messages in thread
From: Kovacs Zoltan Sandor @ 2000-12-14 16:17 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: more odbc patches
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:15 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Re: more odbc patches Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:07 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 16:13 ` Re: more odbc patches Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:17 ` Re: more odbc patches Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
@ 2000-12-14 18:17 ` Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 0 replies; 18+ messages in thread
From: Adam Lang @ 2000-12-14 18:17 UTC (permalink / raw)
To: ; +Cc: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2001-01-24 09:52 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-12-14 13:58 more odbc patches Max Khon <fjoe@iclub.nsu.ru>
2000-12-14 14:04 ` Max Khon <fjoe@iclub.nsu.ru>
2000-12-15 19:12 ` Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-16 09:10 ` Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 04:45 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 09:12 ` Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 11:15 ` Cedar Cox <cedarc@visionforisrael.com>
2001-01-23 18:05 ` Max Khon <fjoe@iclub.nsu.ru>
2001-01-23 20:32 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-24 09:52 ` Cedar Cox <cedarc@visionforisrael.com>
2001-01-23 20:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-14 14:15 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:08 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-12-14 16:02 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:07 ` Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 16:13 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-14 16:17 ` Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
2000-12-14 18:17 ` Adam Lang <aalang@rutgersinsurance.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox