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 по дате отправления: