From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] targetlist functions part 1 (was targetlist |
Date: | 2003-01-22 20:42:54 |
Message-ID: | Pine.LNX.4.44.0301221924180.789-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane writes:
> > With sufficiently blurred vision one might even find SQL99's clause
> > <collection derived table> ::=
> > UNNEST <left paren> <collection value expression> <right paren>
> > applicable. Or maybe not.
>
> Hm. I'm not sure what UNNEST does, but now that you bring SQL99 into
> the picture, what about WITH? That might solve the problem, because
> (I think) WITH tables are logically determined before the main SELECT
> begins to execute.
The SQL 200x draft defines a new clause TABLE ( <collection value
expression> ) as a possible <table primary>, where the <collection value
expression> is required to be a function call. At the end this just boils
down to UNNEST, though. UNNEST is defined in terms of a hairy recursive
join subquery with a LATERAL( ) around it. LATERAL(subquery) is the same
as just (subquery) except that the scope clauses are different. So I
think this is probably what we ought to look at.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-01-22 20:43:28 | Re: Win32 port patches submitted |
Previous Message | Curtis Faith | 2003-01-22 20:38:33 | Re: Windows Build System |
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-01-23 00:33:11 | SEQUENCEs and NO MAXVALUE NO MINVALUE |
Previous Message | Tom Lane | 2003-01-21 21:37:07 | Re: targetlist functions part 1 (was [HACKERS] targetlist |