Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitf7d979b

Browse files
committed
Fix ODBC for new binary fopen/open params
1 parenteae8bd7 commitf7d979b

File tree

3 files changed

+191
-6
lines changed

3 files changed

+191
-6
lines changed

‎doc/TODO.detail/inherit

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -347,3 +347,172 @@ numbers in many other, more commonly exercised, code paths.)
347347

348348
************
349349

350+
From owner-pgsql-hackers@hub.org Tue Jan 25 18:34:14 2000
351+
Received: from hub.org (hub.org [216.126.84.1])
352+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA04935
353+
for <pgman@candle.pha.pa.us>; Tue, 25 Jan 2000 19:34:13 -0500 (EST)
354+
Received: from localhost (majordom@localhost)
355+
by hub.org (8.9.3/8.9.3) with SMTP id TAA31870;
356+
Tue, 25 Jan 2000 19:22:44 -0500 (EST)
357+
(envelope-from owner-pgsql-hackers)
358+
Received: by hub.org (bulk_mailer v1.5); Tue, 25 Jan 2000 19:21:06 -0500
359+
Received: (from majordom@localhost)
360+
by hub.org (8.9.3/8.9.3) id TAA31364
361+
for pgsql-hackers-outgoing; Tue, 25 Jan 2000 19:20:07 -0500 (EST)
362+
(envelope-from owner-pgsql-hackers@postgreSQL.org)
363+
Received: from hu.tm.ee (ppp809.tele2.ee [212.107.37.109])
364+
by hub.org (8.9.3/8.9.3) with ESMTP id TAA31158
365+
for <pgsql-hackers@postgreSQL.org>; Tue, 25 Jan 2000 19:19:04 -0500 (EST)
366+
(envelope-from hannu@tm.ee)
367+
Received: from tm.ee (localhost [127.0.0.1])
368+
by hu.tm.ee (Postfix) with ESMTP
369+
id 46B6213469; Wed, 26 Jan 2000 02:25:13 +0200 (EET)
370+
Message-ID: <388E3EE9.46880647@tm.ee>
371+
Date: Wed, 26 Jan 2000 02:25:13 +0200
372+
From: Hannu Krosing <hannu@tm.ee>
373+
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
374+
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
375+
X-Accept-Language: en
376+
MIME-Version: 1.0
377+
To: Don Baccus <dhogaza@pacifier.com>
378+
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
379+
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
380+
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
381+
Subject: Re: Happy column adding (was RE: [HACKERS] Happy columndropping)
382+
References: <3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com>
383+
<20000125114453.E423@rice.edu>
384+
<001401bf6704$5ca7e3a0$2801007e@tpf.co.jp>
385+
<Pine.GSO.4.02A.10001251152160.11899-100000@Val.DoCS.UU.SE>
386+
<3.0.1.32.20000125080125.00f7f160@mail.pacifier.com>
387+
<20000125114453.E423@rice.edu>
388+
<3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com> <3.0.1.32.20000125151022.00f8c4c0@mail.pacifier.com>
389+
Content-Type: text/plain; charset=us-ascii
390+
Content-Transfer-Encoding: 7bit
391+
Sender: owner-pgsql-hackers@postgreSQL.org
392+
Status: OR
393+
394+
Don Baccus wrote:
395+
>
396+
> Ahhh...yes. I haven't looked at the inheritance code, yet, but I see
397+
> what you're saying. I think. Do child-table columns follow parent-table
398+
> columns by some chance (in today's absolute column number scheme)?
399+
>
400+
> >If we were willing to hardwire the assumption that DROP COLUMN never
401+
> >physically drops a column, but only hides it and adjusts logical column
402+
> >numbers, then the physical column numbers could serve as permanent IDs;
403+
> >so we'd only need two numbers not three. This might be good, or not.
404+
>
405+
> Yes. But if I'm right about how child-table columns are numbered,
406+
> wouldn't add column still cause a problem, i.e. you'd still have to
407+
> change their physical column number?
408+
409+
If we allow deleted column as a basic feature of postgres,
410+
it could be like that
411+
412+
base: COL1 | COL2 | COL3
413+
child: COL1 | COL2 | COL3 | COL4
414+
415+
after add column 5 to base table
416+
417+
base: COL1 | COL2 | COL3 | del4 | COL5
418+
child: COL1 | COL2 | COL3 | COL4 | COL5
419+
420+
after add column 6 to child
421+
422+
base: COL1 | COL2 | COL3 | del4 | COL5
423+
child: COL1 | COL2 | COL3 | COL4 | COL5 | COL6
424+
425+
after drop column 2 from base table
426+
427+
base: COL1 | del2 | COL3 | del4 | COL5
428+
child: COL1 | del2 | COL3 | COL4 | COL5 | COL6
429+
430+
dropping column from child table that is not a deleted column in
431+
parent is not allowed.
432+
433+
The delN columns are always NULLed on reading tuple and are written as proper
434+
null columns (taking up space only in NULL bitmask)
435+
436+
multiple inheritance is tricky and _requires_ unique column ids maybe oids
437+
from pg_attribute to be doable.
438+
439+
-----------------
440+
Hannu
441+
442+
************
443+
444+
From owner-pgsql-hackers@hub.org Thu Jan 27 11:48:26 2000
445+
Received: from hub.org (hub.org [216.126.84.1])
446+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA25953
447+
for <pgman@candle.pha.pa.us>; Thu, 27 Jan 2000 12:48:25 -0500 (EST)
448+
Received: from localhost (majordom@localhost)
449+
by hub.org (8.9.3/8.9.3) with SMTP id MAA22723;
450+
Thu, 27 Jan 2000 12:39:27 -0500 (EST)
451+
(envelope-from owner-pgsql-hackers)
452+
Received: by hub.org (bulk_mailer v1.5); Thu, 27 Jan 2000 12:36:16 -0500
453+
Received: (from majordom@localhost)
454+
by hub.org (8.9.3/8.9.3) id MAA22021
455+
for pgsql-hackers-outgoing; Thu, 27 Jan 2000 12:35:23 -0500 (EST)
456+
(envelope-from owner-pgsql-hackers@postgreSQL.org)
457+
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
458+
by hub.org (8.9.3/8.9.3) with ESMTP id MAA21886
459+
for <pgsql-hackers@postgresql.org>; Thu, 27 Jan 2000 12:34:47 -0500 (EST)
460+
(envelope-from peter@localhost.its.uu.se)
461+
Received: from regulus.its.uu.se ([130.238.7.19]:61911 "EHLO regulus.its.uu.se")
462+
by merganser.its.uu.se with ESMTP id <S294955AbQA0ReG>;
463+
Thu, 27 Jan 2000 18:34:06 +0100
464+
Received: from peter (helo=localhost)
465+
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
466+
id 12DsvR-0000HH-00; Thu, 27 Jan 2000 18:41:45 +0100
467+
Date: Thu, 27 Jan 2000 18:41:45 +0100 (CET)
468+
From: Peter Eisentraut <peter_e@gmx.net>
469+
To: Tom Lane <tgl@sss.pgh.pa.us>
470+
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
471+
Subject: Re: [HACKERS] Column ADDing issues
472+
In-Reply-To: <15550.948845404@sss.pgh.pa.us>
473+
Message-ID: <Pine.LNX.4.21.0001262020480.416-100000@localhost.localdomain>
474+
MIME-Version: 1.0
475+
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
476+
Content-Transfer-Encoding: 8BIT
477+
Sender: owner-pgsql-hackers@postgreSQL.org
478+
Status: ORr
479+
480+
On 2000-01-25, Tom Lane mentioned:
481+
482+
> > Everything has its order and it's not like the inheritance as such is
483+
> > broken.
484+
>
485+
> Yes, a whole bunch of stuff is broken after this happens. Go back and
486+
> consult the archives --- or maybe Chris Bitmead will fill you in; he's
487+
> got plenty of scars to show for this set of problems. (All I recall
488+
> offhand is that pg_dump and reload can fail to generate a working
489+
> database.) The bottom line is that it would be a lot nicer if column c
490+
> had the same column position in both the parent table and the child
491+
> table(s).
492+
493+
This should be fixed in pg_dump by infering something via the oids of the
494+
pg_attribute entries. No need to mess up the backend for it.
495+
496+
Maybe pg_dump should optionally dump schemas in terms of insert into
497+
pg_something commands rather than actual DDL. ;)
498+
499+
>
500+
> I suggest you be very cautious about messing with ALTER TABLE until you
501+
> understand why inheritance makes it such a headache ;-)
502+
503+
I'm just trying to get the defaults and constraints working. If
504+
inheritance stays broken the way it previously was, it's beyond my
505+
powers. But I get the feeling that people rather not alter their tables
506+
unless they have *perfect* alter table commands. I don't feel like arguing
507+
with them, they'll just have to do without then.
508+
509+
510+
--
511+
Peter Eisentraut Sernanders v�g 10:115
512+
peter_e@gmx.net 75262 Uppsala
513+
http://yi.org/peter-e/ Sweden
514+
515+
516+
517+
************
518+

‎doc/src/FAQ.html

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -725,11 +725,13 @@ <H4><A NAME="3.11">3.11</A>) What debugging features are available in
725725
semicolon. If you have compiled with debugging symbols, you can use a
726726
debugger to see what is happening. Because the backend was not started
727727
from the postmaster, it is not running in an identical environment and
728-
locking/backend interaction problems may not be duplicated. Some
729-
debuggers can attach to an already-running backend; that is the most
730-
convenient way to diagnose problems in the normal multi-backend
731-
environment.
732-
<P>
728+
locking/backend interaction problems may not be duplicated.<P>
729+
730+
Another method is to start<I>psql</I> in one window, then find the
731+
<small>PID</small> of the<i>postgres</i> process being used by the
732+
<i>psql.</i> Use a debugger to attach to the<i>postgres</i>
733+
<small>PID.</small> You can set breakpoints in the debugger and issues
734+
queries from<i>psql.</i>
733735

734736
The postgres program has -s, -A, and -t options that can be very useful
735737
for debugging and performance measurements.<P>
@@ -1061,7 +1063,11 @@ <H4><A NAME="4.16.2">4.16.2</A>) How do I get the back the generated SERIAL valu
10611063
INSERT INTO person (name) VALUES ('Blaise Pascal');
10621064
$newID = currval('person_id_seq');
10631065
</PRE>
1064-
Finally, you could use the<AHREF="#4.17">oid</A> 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().
1066+
Finally, you could use the<AHREF="#4.17">oid</A> returned from the
1067+
INSERT statement to lookup the default value, though this is probably
1068+
the least portable approach. In perl, using DBI with Edmund Mergl's
1069+
DBD::Pg module, the oid value is made available via
1070+
$sth-&gt;{pg_oid_status} after $sth-&gt;execute().
10651071

10661072
<H4><ANAME="4.16.3">4.16.3</A>) Don't currval() and nextval() lead to a race condition with other
10671073
concurrent backend processes?</H4><P>

‎src/interfaces/odbc/psqlodbc.h

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,16 @@ typedef UInt4 Oid;
4949
#defineDRIVER_FILE_NAME"libpsqlodbc.so"
5050
#endif
5151

52+
#ifdefWIN32
53+
#definePG_BINARYO_BINARY
54+
#definePG_BINARY_R"rb"
55+
#definePG_BINARY_W"wb"
56+
#else
57+
#definePG_BINARY0
58+
#definePG_BINARY_R"r"
59+
#definePG_BINARY_W"w"
60+
#endif
61+
5262
/* Limits */
5363
#ifdefWIN32
5464
#defineBLCKSZ 4096

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp