Re: [HACKERS] Re: subselects

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: [HACKERS] Re: subselects
Дата
Msg-id Pine.NEB.3.96.980110144716.259B-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: subselects  ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>)
Список 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 по дате отправления:

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Can't run current PostgreSQL
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] Re: subselects