inherit 13.9 KB
Newer Older
Bruce Momjian's avatar
Bruce Momjian committed
1 2 3 4
From owner-pgsql-hackers@hub.org Tue Jun  1 22:31:18 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA09988
	for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:31:17 -0400 (EDT)
Bruce Momjian's avatar
Bruce Momjian committed
5
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id WAA18944 for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:08:09 -0400 (EDT)
Bruce Momjian's avatar
Bruce Momjian committed
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
Received: from hub.org (hub.org [209.167.229.1])
	by hub.org (8.9.3/8.9.3) with ESMTP id WAA75604;
	Tue, 1 Jun 1999 22:01:31 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 01 Jun 1999 22:01:11 +0000 (EDT)
Received: (from majordom@localhost)
	by hub.org (8.9.3/8.9.3) id WAA75519
	for pgsql-hackers-outgoing; Tue, 1 Jun 1999 22:01:09 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from localhost.localdomain (h246.ozemail2.ozemail.com.au [203.108.14.246])
	by hub.org (8.9.3/8.9.3) with ESMTP id WAA75452
	for <pgsql-hackers@hub.org>; Tue, 1 Jun 1999 22:00:50 -0400 (EDT)
	(envelope-from chris.bitmead@bigfoot.com)
Received: from bigfoot.com (localhost [127.0.0.1])
	by localhost.localdomain (8.8.7/8.8.7) with ESMTP id KAA04059
	for <pgsql-hackers@hub.org>; Wed, 2 Jun 1999 10:50:11 +1000
Message-ID: <37547FC3.40106A5E@bigfoot.com>
Date: Wed, 02 Jun 1999 10:50:11 +1000
From: Chris Bitmead <chris.bitmead@bigfoot.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] ALTER TABLE ADD COLUMN
References: <199906011436.KAA23479@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO

Bruce Momjian wrote:

> Our TODO now has:
> 
>         * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> 
> I don't think any of us understand the issues on this one.

Let me guess at the problem. When you add a column, it doesn't change
all the records, therefore the column must be added at the end. This
means that the columns will not be in the same order as if you had
created them from scratch.

There seem to be three solutions:
a) Go to a much more sophisticated schema system, with versions and
version numbers (fairly hard but desirable to fix other schema change
problems). Then insert the column in the position it is supposed to be
in.

b) Fix the copy command to input and output the columns, not in the
order they are in, but in the order they would be in on re-creation.

c) make the copy command take arguments specifying the field names, like
INSERT can do.

I think it would be good if Postgres had all 3 features. Probably (b) is
the least work.


Bruce Momjian's avatar
Bruce Momjian committed
67 68 69 70
From owner-pgsql-general@hub.org Fri Jul  9 04:01:16 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id EAA22565
	for <maillist@candle.pha.pa.us>; Fri, 9 Jul 1999 04:01:15 -0400 (EDT)
Bruce Momjian's avatar
Bruce Momjian committed
71
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id DAA10238 for <maillist@candle.pha.pa.us>; Fri, 9 Jul 1999 03:56:46 -0400 (EDT)
Bruce Momjian's avatar
Bruce Momjian committed
72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
Received: from hub.org (hub.org [209.167.229.1])
	by hub.org (8.9.3/8.9.3) with ESMTP id DAA79895;
	Fri, 9 Jul 1999 03:53:13 -0400 (EDT)
	(envelope-from owner-pgsql-general@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 09 Jul 1999 03:47:45 +0000 (EDT)
Received: (from majordom@localhost)
	by hub.org (8.9.3/8.9.3) id DAA79076
	for pgsql-general-outgoing; Fri, 9 Jul 1999 03:47:43 -0400 (EDT)
	(envelope-from owner-pgsql-general@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
Received: from ns.idianet.net ([195.154.201.1])
	by hub.org (8.9.3/8.9.3) with ESMTP id DAA79054
	for <pgsql-general@postgreSQL.org>; Fri, 9 Jul 1999 03:47:37 -0400 (EDT)
	(envelope-from haj@idianet.net)
Received: from kosovo (ppp150-paris2.isdnet.net [194.149.182.150])
	by ns.idianet.net (8.9.1/8.9.1) with SMTP id JAA08143;
	Fri, 9 Jul 1999 09:43:35 +0200 (CEST)
Message-ID: <000c01bec9df$3704bd20$0601a8c0@kosovo.idianet.net>
Reply-To: "Jonathan davis" <haj@idianet.net>
From: "Jonathan davis" <haj@idianet.net>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "Pgsql-General@Postgresql. Org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] just little BUG
Date: Fri, 9 Jul 1999 09:46:42 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-pgsql-general@postgreSQL.org
Precedence: bulk
Status: ROr



>[Charset iso-8859-1 unsupported, filtering to ASCII...]
>> hello all
>> 
>> normaly a UNIQUE PRIMARY KEY is unique but 
>> when you use a heritage, you can insert a duplicate key !!!!
>
>I assume you mean inheritance.
>
>Can you send us a little test sample please? 
>
>-- 
hello all

this is the problem:

example:

test=> CREATE TABLE MAN(name char(10) UNIQUE PRIMARY KEY);T

test=> CREATE TABLE PROFESSOR(scool char(20))INHERITS(MAN);

test=> INSERT INTO PROFESSOR(name) VALUES('DAVIS');
INSERT 54424 1

test=> INSERT INTO PROFESSOR(name) VALUES('DAVIS');
INSERT 54425 1









145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269
From owner-pgsql-hackers@hub.org Tue Apr 20 10:34:34 1999
Received: from hub.org (hub.org [209.47.145.100])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA28480
	for <maillist@candle.pha.pa.us>; Tue, 20 Apr 1999 10:34:31 -0400 (EDT)
Received: from localhost (majordom@localhost)
	by hub.org (8.9.3/8.9.1) with SMTP id KAA12281;
	Tue, 20 Apr 1999 10:33:22 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 20 Apr 1999 10:32:04 +0000 (EDT)
Received: (from majordom@localhost)
	by hub.org (8.9.3/8.9.1) id KAA11432
	for pgsql-hackers-outgoing; Tue, 20 Apr 1999 10:32:01 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net [139.130.75.122])
	by hub.org (8.9.3/8.9.1) with ESMTP id KAA11378
	for <hackers@postgreSQL.org>; Tue, 20 Apr 1999 10:31:52 -0400 (EDT)
	(envelope-from chris.bitmead@bigfoot.com)
Received: from bigfoot.com (chris@localhost [127.0.0.1])
	by tech.com.au (8.8.7/8.8.7) with ESMTP id AAA21255
	for <hackers@postgreSQL.org>; Wed, 21 Apr 1999 00:31:32 +1000
Message-ID: <371C8FC3.4804CF87@bigfoot.com>
Date: Tue, 20 Apr 1999 14:31:31 +0000
From: Chris Bitmead <chris.bitmead@bigfoot.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Heads up: does RULES regress test still work for you?
References: <199904151054.UAA07367@tech.com.au> <3715C69E.AE517ADB@bigfoot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO


Does the following indicate a bug? It sure is wierd. Maybe some of these
statements aren't supported by postgresql (??), but the outcome doesn't
make sense to me.

httpd=> CREATE TABLE x (y text);
CREATE
httpd=> CREATE VIEW z AS select * from x;
CREATE
httpd=> CREATE TABLE a (b text) INHERITS(z);
CREATE
httpd=> INSERT INTO x VALUES ('foo');
INSERT 168602 1
httpd=> select * from z*;
y  
---
foo
foo
(2 rows)

How did we suddenly get two rows??

-- 
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com


From owner-pgsql-hackers@hub.org Tue May 25 11:01:16 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA15867
	for <maillist@candle.pha.pa.us>; Tue, 25 May 1999 11:01:16 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id KAA10712 for <maillist@candle.pha.pa.us>; Tue, 25 May 1999 10:55:17 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
	by hub.org (8.9.3/8.9.3) with ESMTP id KAA07206;
	Tue, 25 May 1999 10:45:50 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 25 May 1999 10:43:02 +0000 (EDT)
Received: (from majordom@localhost)
	by hub.org (8.9.3/8.9.3) id KAA06706
	for pgsql-hackers-outgoing; Tue, 25 May 1999 10:43:01 -0400 (EDT)
	(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.3/8.9.3) with ESMTP id KAA06690
	for <pgsql-hackers@postgreSQL.org>; Tue, 25 May 1999 10:42:57 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA02984
	for <pgsql-hackers@postgreSQL.org>; Tue, 25 May 1999 10:42:39 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] INSERT INTO view means what exactly?
Date: Tue, 25 May 1999 10:42:39 -0400
Message-ID: <2981.927643359@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: ROr

With current sources:

regression=> CREATE TABLE x (y text);
CREATE
regression=> CREATE VIEW z AS select * from x;
CREATE
regression=> INSERT INTO x VALUES ('foo');
INSERT 411635 1
regression=> INSERT INTO z VALUES ('bar');
INSERT 411636 1
regression=> select * from x;
y
---
foo
(1 row)

regression=> select * from z;
y
---
foo
(1 row)

OK, where'd tuple 411636 go?  Seems to me that the insert should either
have been rejected or caused an insert into x, depending on how
transparent you think views are (I always thought they were
read-only?).  Dropping the data into never-never land and giving a
misleading success response code is not my idea of proper behavior.

			regards, tom lane


Bruce Momjian's avatar
Bruce Momjian committed
270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349
From owner-pgsql-hackers@hub.org Mon Jan 24 23:46:25 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 XAA25453
	for <pgman@candle.pha.pa.us>; Mon, 24 Jan 2000 23:46:24 -0500 (EST)
Received: from localhost (majordom@localhost)
	by hub.org (8.9.3/8.9.3) with SMTP id XAA81794;
	Mon, 24 Jan 2000 23:01:22 -0500 (EST)
	(envelope-from owner-pgsql-hackers)
Received: by hub.org (bulk_mailer v1.5); Mon, 24 Jan 2000 22:59:46 -0500
Received: (from majordom@localhost)
	by hub.org (8.9.3/8.9.3) id WAA80721
	for pgsql-hackers-outgoing; Mon, 24 Jan 2000 22:58:59 -0500 (EST)
	(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id WAA80619
	for <pgsql-hackers@postgreSQL.org>; Mon, 24 Jan 2000 22:58:33 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11576;
	Mon, 24 Jan 2000 22:57:12 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>, "Peter Eisentraut" <peter_e@gmx.net>,
        "PostgreSQL Development" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping 
In-reply-to: <3.0.1.32.20000124184137.01069490@mail.pacifier.com> 
References: <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <3.0.1.32.20000124184137.01069490@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
	message dated "Mon, 24 Jan 2000 18:41:37 -0800"
Date: Mon, 24 Jan 2000 22:57:12 -0500
Message-ID: <11573.948772632@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Status: RO

Don Baccus <dhogaza@pacifier.com> writes:
> Just a reality check for my learning of the internals.  Out of curiousity
> I coincidently have spent the last hour looking to see how add column's
> implemented.  It doesn't appear to do anything other than the new attribute
> to the proper system table.  heap_getattr() just returns null if you ask
> for an attribute past the end of the tuple.  

> This would appear to be (at least one reason) why you can't add a "not null"
> constraint to a column you're adding to an existing relation, or set the
> new column to some non-null default value.

> Correct?  (again, to see if my eyeballs and brain are working in synch
> tonight)

Yup, that's about the size of it.  ADD COLUMN doesn't actually touch the
table itself, so it can only add a column that's initially all NULLs.
And even this depends on some uncomfortable assumptions about the
robustness of heap_getattr().  I have always wondered whether it works
if you ADD COLUMN a 33'rd column (or anything that is just past the
next padding boundary for the null-values bitmap).

Another problem with it is seen when you do a recursive ADD COLUMN in
an inheritance tree.  The added column has the first free column number
in each table, which generally means that it has different numbers in
the children than in the parent.  There are some kluges to make this
sort-of-work for simple cases, but a lot of stuff fails unpleasantly
--- Chris Bitmead can show you some scars from that, IIRC.

> Does your comment imply that it's planned to change this, i.e. actually
> add the new column to each tuple in the relation rather than use the
> existing, somewhat elegant hack?

That's what I would like to see: all the children should have the
same column numbers for all columns that they inherit from the parent.

(Now, this would mean not only physically altering the tuples of
the children, but also renumbering their added columns, which has
implications on stored rules and triggers and so forth.  It'd be
painful, no doubt about it.  Still, I'd rather pay the price in the
seldom-used ADD COLUMN case than try to deal with out-of-sync column
numbers in many other, more commonly exercised, code paths.)

			regards, tom lane

************