Re: [HACKERS] Heads up: does RULES regress test still work for you?
This is so weird, I can't even explain it.
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
--
Bruce Momjian | http://www.op.net/~candle
maillist@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
Import Notes
Reply to msg id not found: 371C8FC3.4804CF87@bigfoot.com
This is so weird, I can't even explain it.
I can reproduce it - yes totally weird :-)
Can only guess where the problem might be, because I'm not
familiar with inheritance and the underlying code. I think
it's the fact that after rewriting the wrong RTE (that one of
the view z which isn't referenced any more) is marked 'inh
true'.
Seems that the inheritance is resolved AFTER the rewriting
somewhere in the planner. If that's true, inheriting of views
might become a very tricky (maybe impossible) thing at all.
How could someone inherit a join? Which RTE's of a view
should be marked 'inh true' then?
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-- Bruce Momjian | http://www.op.net/~candle maillist@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
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
jwieck@debis.com (Jan Wieck) writes:
This is so weird, I can't even explain it.
I can reproduce it - yes totally weird :-)
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??
Is it a bug? It looks to me like a inherited z's view of x (and thus
when you selected from both a and z by using "z*", you got x's contents
twice). Is that wrong? If so, why?
If inheriting from a view is allowed at all (maybe it shouldn't be),
then I'd *expect* the view-ness to be inherited.
Offhand, given that tables and views are different kinds of things,
allowing a table to inherit from a view seems like a bad idea.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue25May1999154749+0200m10mHYb-000EBPC@orion.SAPserv.Hamburg.dsh.de | Resolved by subject fallback