From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] subselects coding started |
Date: | 1998-01-18 12:27:09 |
Message-ID: | 34C1F51D.E9CF0A39@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas G. Lockhart wrote:
>
> Bruce Momjian wrote:
>
> > OK, I have created the SubLink structure with supporting routines, and
> > have added code to create the SubLink structures in the parser, and have
> > added Query->hasSubLink.
> >
> > I changed gram.y to support:
> >
> > (x,y,z) OP (subselect)
> >
> > where OP is any operator. Is that right, or are we doing only certain
> > ones, and of so, do we limit it in the parser?
>
> Seems like we would want to pass most operators and expressions through
> gram.y, and then call elog() in either the transformation or in the
> optimizer if it is an operator which can't be supported.
Not in optimizer, in parser, please.
Remember that for <> SubLink->useor must be TRUE and this is parser work
(optimizer don't know about "=", "<>", etc but only about Oper nodes).
IN ("=" ANY) and NOT IN ("<>" ALL) transformations are also parser work.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Vicherek | 1998-01-18 18:36:30 | Re: [HACKERS] non-SQL C interface ? (fwd) |
Previous Message | Peter T Mount | 1998-01-18 11:34:54 | Re: [HACKERS] non-SQL C interface ? (fwd) |