From f7d979bc58736d48ac1f44e5d638173aa172e87e Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 8 Jun 2000 16:40:51 +0000 Subject: [PATCH] Fix ODBC for new binary fopen/open params --- doc/TODO.detail/inherit | 169 +++++++++++++++++++++++++++++++++ doc/src/FAQ.html | 18 ++-- src/interfaces/odbc/psqlodbc.h | 10 ++ 3 files changed, 191 insertions(+), 6 deletions(-) diff --git a/doc/TODO.detail/inherit b/doc/TODO.detail/inherit index a80e0c77fc..cd2a78a911 100644 --- a/doc/TODO.detail/inherit +++ b/doc/TODO.detail/inherit @@ -347,3 +347,172 @@ numbers in many other, more commonly exercised, code paths.) ************ +From owner-pgsql-hackers@hub.org Tue Jan 25 18:34:14 2000 +Received: from hub.org (hub.org [216.126.84.1]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA04935 + for ; Tue, 25 Jan 2000 19:34:13 -0500 (EST) +Received: from localhost (majordom@localhost) + by hub.org (8.9.3/8.9.3) with SMTP id TAA31870; + Tue, 25 Jan 2000 19:22:44 -0500 (EST) + (envelope-from owner-pgsql-hackers) +Received: by hub.org (bulk_mailer v1.5); Tue, 25 Jan 2000 19:21:06 -0500 +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id TAA31364 + for pgsql-hackers-outgoing; Tue, 25 Jan 2000 19:20:07 -0500 (EST) + (envelope-from owner-pgsql-hackers@postgreSQL.org) +Received: from hu.tm.ee (ppp809.tele2.ee [212.107.37.109]) + by hub.org (8.9.3/8.9.3) with ESMTP id TAA31158 + for ; Tue, 25 Jan 2000 19:19:04 -0500 (EST) + (envelope-from hannu@tm.ee) +Received: from tm.ee (localhost [127.0.0.1]) + by hu.tm.ee (Postfix) with ESMTP + id 46B6213469; Wed, 26 Jan 2000 02:25:13 +0200 (EET) +Message-ID: <388E3EE9.46880647@tm.ee> +Date: Wed, 26 Jan 2000 02:25:13 +0200 +From: Hannu Krosing +Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?= +X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686) +X-Accept-Language: en +MIME-Version: 1.0 +To: Don Baccus +Cc: Tom Lane , + "Ross J. Reedstrom" , + PostgreSQL Development +Subject: Re: Happy column adding (was RE: [HACKERS] Happy columndropping) +References: <3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com> + <20000125114453.E423@rice.edu> + <001401bf6704$5ca7e3a0$2801007e@tpf.co.jp> + + <3.0.1.32.20000125080125.00f7f160@mail.pacifier.com> + <20000125114453.E423@rice.edu> + <3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com> <3.0.1.32.20000125151022.00f8c4c0@mail.pacifier.com> +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Sender: owner-pgsql-hackers@postgreSQL.org +Status: OR + +Don Baccus wrote: +> +> Ahhh...yes. I haven't looked at the inheritance code, yet, but I see +> what you're saying. I think. Do child-table columns follow parent-table +> columns by some chance (in today's absolute column number scheme)? +> +> >If we were willing to hardwire the assumption that DROP COLUMN never +> >physically drops a column, but only hides it and adjusts logical column +> >numbers, then the physical column numbers could serve as permanent IDs; +> >so we'd only need two numbers not three. This might be good, or not. +> +> Yes. But if I'm right about how child-table columns are numbered, +> wouldn't add column still cause a problem, i.e. you'd still have to +> change their physical column number? + +If we allow deleted column as a basic feature of postgres, +it could be like that + +base: COL1 | COL2 | COL3 +child: COL1 | COL2 | COL3 | COL4 + +after add column 5 to base table + +base: COL1 | COL2 | COL3 | del4 | COL5 +child: COL1 | COL2 | COL3 | COL4 | COL5 + +after add column 6 to child + +base: COL1 | COL2 | COL3 | del4 | COL5 +child: COL1 | COL2 | COL3 | COL4 | COL5 | COL6 + +after drop column 2 from base table + +base: COL1 | del2 | COL3 | del4 | COL5 +child: COL1 | del2 | COL3 | COL4 | COL5 | COL6 + +dropping column from child table that is not a deleted column in +parent is not allowed. + +The delN columns are always NULLed on reading tuple and are written as proper +null columns (taking up space only in NULL bitmask) + +multiple inheritance is tricky and _requires_ unique column ids maybe oids +from pg_attribute to be doable. + +----------------- +Hannu + +************ + +From owner-pgsql-hackers@hub.org Thu Jan 27 11:48:26 2000 +Received: from hub.org (hub.org [216.126.84.1]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA25953 + for ; Thu, 27 Jan 2000 12:48:25 -0500 (EST) +Received: from localhost (majordom@localhost) + by hub.org (8.9.3/8.9.3) with SMTP id MAA22723; + Thu, 27 Jan 2000 12:39:27 -0500 (EST) + (envelope-from owner-pgsql-hackers) +Received: by hub.org (bulk_mailer v1.5); Thu, 27 Jan 2000 12:36:16 -0500 +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id MAA22021 + for pgsql-hackers-outgoing; Thu, 27 Jan 2000 12:35:23 -0500 (EST) + (envelope-from owner-pgsql-hackers@postgreSQL.org) +Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236]) + by hub.org (8.9.3/8.9.3) with ESMTP id MAA21886 + for ; Thu, 27 Jan 2000 12:34:47 -0500 (EST) + (envelope-from peter@localhost.its.uu.se) +Received: from regulus.its.uu.se ([130.238.7.19]:61911 "EHLO regulus.its.uu.se") + by merganser.its.uu.se with ESMTP id ; + Thu, 27 Jan 2000 18:34:06 +0100 +Received: from peter (helo=localhost) + by regulus.its.uu.se with local-esmtp (Exim 3.02 #2) + id 12DsvR-0000HH-00; Thu, 27 Jan 2000 18:41:45 +0100 +Date: Thu, 27 Jan 2000 18:41:45 +0100 (CET) +From: Peter Eisentraut +To: Tom Lane +cc: PostgreSQL Development +Subject: Re: [HACKERS] Column ADDing issues +In-Reply-To: <15550.948845404@sss.pgh.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=ISO-8859-1 +Content-Transfer-Encoding: 8BIT +Sender: owner-pgsql-hackers@postgreSQL.org +Status: ORr + +On 2000-01-25, Tom Lane mentioned: + +> > Everything has its order and it's not like the inheritance as such is +> > broken. +> +> Yes, a whole bunch of stuff is broken after this happens. Go back and +> consult the archives --- or maybe Chris Bitmead will fill you in; he's +> got plenty of scars to show for this set of problems. (All I recall +> offhand is that pg_dump and reload can fail to generate a working +> database.) The bottom line is that it would be a lot nicer if column c +> had the same column position in both the parent table and the child +> table(s). + +This should be fixed in pg_dump by infering something via the oids of the +pg_attribute entries. No need to mess up the backend for it. + +Maybe pg_dump should optionally dump schemas in terms of insert into +pg_something commands rather than actual DDL. ;) + +> +> I suggest you be very cautious about messing with ALTER TABLE until you +> understand why inheritance makes it such a headache ;-) + +I'm just trying to get the defaults and constraints working. If +inheritance stays broken the way it previously was, it's beyond my +powers. But I get the feeling that people rather not alter their tables +unless they have *perfect* alter table commands. I don't feel like arguing +with them, they'll just have to do without then. + + +-- +Peter Eisentraut Sernanders väg 10:115 +peter_e@gmx.net 75262 Uppsala +http://yi.org/peter-e/ Sweden + + + +************ + diff --git a/doc/src/FAQ.html b/doc/src/FAQ.html index e30f4153bf..19344f9322 100644 --- a/doc/src/FAQ.html +++ b/doc/src/FAQ.html @@ -725,11 +725,13 @@ debugging purposes. Note that a newline terminates the query, not a semicolon. If you have compiled with debugging symbols, you can use a debugger to see what is happening. Because the backend was not started from the postmaster, it is not running in an identical environment and -locking/backend interaction problems may not be duplicated. Some -debuggers can attach to an already-running backend; that is the most -convenient way to diagnose problems in the normal multi-backend -environment. -

+locking/backend interaction problems may not be duplicated.

+ +Another method is to start psql in one window, then find the +PID of the postgres process being used by the +psql. Use a debugger to attach to the postgres +PID. You can set breakpoints in the debugger and issues +queries from psql. The postgres program has -s, -A, and -t options that can be very useful for debugging and performance measurements.

@@ -1061,7 +1063,11 @@ Similarly, you could retrieve the just-assigned SERIAL value with the currval INSERT INTO person (name) VALUES ('Blaise Pascal'); $newID = currval('person_id_seq'); -Finally, you could use the oid returned from the INSERT statement to lookup the default value, though this is probably the least portable approach. In perl, using DBI with Edmund Mergl's DBD::Pg module, the oid value is made available via $sth->{pg_oid_status} after $sth->execute(). +Finally, you could use the oid returned from the +INSERT statement to lookup the default value, though this is probably +the least portable approach. In perl, using DBI with Edmund Mergl's +DBD::Pg module, the oid value is made available via +$sth->{pg_oid_status} after $sth->execute().

4.16.3) Don't currval() and nextval() lead to a race condition with other concurrent backend processes?

diff --git a/src/interfaces/odbc/psqlodbc.h b/src/interfaces/odbc/psqlodbc.h index 5386075df6..ff90903dfe 100644 --- a/src/interfaces/odbc/psqlodbc.h +++ b/src/interfaces/odbc/psqlodbc.h @@ -49,6 +49,16 @@ typedef UInt4 Oid; #define DRIVER_FILE_NAME "libpsqlodbc.so" #endif +#ifdef WIN32 +#define PG_BINARY O_BINARY +#define PG_BINARY_R "rb" +#define PG_BINARY_W "wb" +#else +#define PG_BINARY 0 +#define PG_BINARY_R "r" +#define PG_BINARY_W "w" +#endif + /* Limits */ #ifdef WIN32 #define BLCKSZ 4096