Re: [HACKERS] Re: subselects - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] Re: subselects
Date
Msg-id Pine.NEB.3.96.980110144716.259B-100000@thelab.hub.org
Whole thread Raw
In response to Re: subselects  ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>)
List pgsql-hackers
On Sun, 11 Jan 1998, Vadim B. Mikheev wrote:

> > > No, I don't like to add anything in parser. Example:
> > >
> > >         select *
> > >         from tabA
> > >         where col1 = (select col2
> > >                       from tabB
> > >                       where tabA.col3 = tabB.col4
> > >                       and exists (select *
> > >                                   from tabC
> > >                                   where tabB.colX = tabC.colX and
> > >                                         tabC.colY = tabA.col2)
> > >                      )
> > >
> > > : a column of tabA is referenced in sub-subselect
> >
> > This is a strange case that I don't think we need to handle in our first
> > implementation.
>
> I don't know is this strange case or not :)
> But I would like to know is this allowed by standards - can someone
> comment on this ?
> And I don't see problems with handling this...

    I don't know about "the standards", but in my mind, the above should
work if subselects work...so what if you add a third or fourth level subselect
to the overall query?  IMHO, the "outer most" (inner most?) subselect should
be resolved to provide the "EXISTS" list, the the next should be resolved,
etc...

    Hell...looking at this, I'd almost think that you could use subselects to
force a pseudo-ordering onto a large complex JOIN (ya ya, really messy though)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Can't run current PostgreSQL
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Re: subselects