Thread: 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,
Pennsylvania19026
 

>
>
>
> 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