pg.ddx.io pgsql-patches@postgresql.org mailing list archive
help / color / mirror / Atom feedWITH RECUSIVE patches 0717
11+ messages / 4 participants
[nested] [flat]
* WITH RECUSIVE patches 0717
@ 2008-07-17 09:40 Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: Tatsuo Ishii @ 2008-07-17 09:40 UTC (permalink / raw)
To: pgsql-patches; +Cc: pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
Hi,
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii. (David Fetter's
psql help patches are not included. It seems his git repository has
gone).
This version implements:
- detect certain queries those are not valid acroding to the standard
I also include erroneous query examples created by Yoshiyuki (probably
will become part of regression tests).
Remaining problmes are:
1) sort query names acording to the dependency
2) planner always estimate 0 cost for recursion plans
3) add regression tests
For 1), I have proposed we limit query names to 1, in another word do
not allow mutually recursive queries. For 2) there's no good idea to
solve it, so I suggest leave it as it is now.
For 3) I will generate regression tests as soon as possible.
So the patches seem to be almost ready to commit IMO.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Attachments:
recursive_query.patch.gz (application/octet-stream, 19.8K) download
error.sql (text/plain, 1.8K) download
-- UNION
WITH RECURSIVE x(n) AS (SELECT 1 UNION SELECT n+1 FROM x)
SELECT * FROM x;
-- INTERSECT
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- EXCEPT
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- 再畿３柑項なし
WITH RECURSIVE x(n) AS (SELECT n FROM x)
SELECT * FROM x;
-- 左側瘢雹に再畿３柑項がう３柑る
WITH RECURSIVE x(n) AS (SELECT n FROM x UNION ALL SELECT 1)
SELECT * FROM x;
CREATE TEMP TABLE y (a int);
INSERT INTO y SELECT generate_series(1, 10);
-- LEFT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM y LEFT JOIN x ON x.n = y.a where n < 10)
SELECT * FROM x;
-- RIGHT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM x RIGHT JOIN y ON x.n = y.a where n < 10)
SELECT * FROM x;
-- FULL JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM x FULL JOIN y ON x.n = y.a where n < 10)
SELECT * FROM x;
-- subquery
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n IN (SELECT * FROM x))
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n = 1 AND n IN (SELECT * FROM x))
SELECT * FROM x;
-- GROUP BY
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x GROUP BY n)
SELECT * FROM x;
-- HAVING
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x HAVING n < 10)
SELECT * FROM x;
-- 集約関数
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT count(*) FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT sum(*) FROM x)
SELECT * FROM x;
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-17 16:01 David Fetter <david@fetter.org>
parent: Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Fetter @ 2008-07-17 16:01 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
On Thu, Jul 17, 2008 at 06:40:25PM +0900, Tatsuo Ishii wrote:
> Hi,
>
> Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD used my usual configure option with
only --with-prefix set, then tried to make, and got:
make[3]: *** No rule to make target `parse_cte.o', needed by `objfiles.txt'. Stop.
make[3]: Leaving directory `/home/shackle/pgsql/src/backend/parser'
make[2]: *** [parser-recursive] Error 2
make[2]: Leaving directory `/home/shackle/pgsql/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/shackle/pgsql/src'
make: *** [all] Error 2
Is there something missing?
> (David Fetter's psql help patches are not included. It seems his git
> repository has gone).
I apologize for that. I rearranged it last night because the name was
not scalable, but delayed sending this out until today. It can now be
found at
<http://git.postgresql.org/?p=~davidfetter/with_recursive/.git;a=summary;
To pull from the new location, in your .git/config, change URL from something
like the following:
url = git://davidfetter@git.postgresql.org/git/~davidfetter/postgresql/.git
to
url = git://davidfetter@git.postgresql.org/git/~davidfetter/with_recursive/.git
> This version implements:
>
> - detect certain queries those are not valid acroding to the standard
Great :)
> I also include erroneous query examples created by Yoshiyuki (probably
> will become part of regression tests).
>
> Remaining problmes are:
>
> 1) sort query names acording to the dependency
This can be done at query time already using arrays per Asaba-san's
suggestion. I'll add some examples to the documentation.
> 2) planner always estimate 0 cost for recursion plans
> 3) add regression tests
>
> For 1), I have proposed we limit query names to 1, in another word do
> not allow mutually recursive queries. For 2) there's no good idea to
> solve it, so I suggest leave it as it is now.
>
> For 3) I will generate regression tests as soon as possible.
>
> So the patches seem to be almost ready to commit IMO.
Wonderful!
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-18 01:41 Tatsuo Ishii <ishii@postgresql.org>
parent: David Fetter <david@fetter.org>
0 siblings, 1 reply; 11+ messages in thread
From: Tatsuo Ishii @ 2008-07-18 01:41 UTC (permalink / raw)
To: david@fetter.org; +Cc: pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
> > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
>
> I tried this patch vs. CVS HEAD used my usual configure option with
> only --with-prefix set, then tried to make, and got:
>
> make[3]: *** No rule to make target `parse_cte.o', needed by `objfiles.txt'. Stop.
> make[3]: Leaving directory `/home/shackle/pgsql/src/backend/parser'
> make[2]: *** [parser-recursive] Error 2
> make[2]: Leaving directory `/home/shackle/pgsql/src/backend'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/shackle/pgsql/src'
> make: *** [all] Error 2
>
> Is there something missing?
Oops. I forgot to include patches against newly added files. Please
try included patches.
> > (David Fetter's psql help patches are not included. It seems his git
> > repository has gone).
>
> I apologize for that. I rearranged it last night because the name was
> not scalable, but delayed sending this out until today. It can now be
> found at
>
> <http://git.postgresql.org/?p=~davidfetter/with_recursive/.git;a=summary;
>
> To pull from the new location, in your .git/config, change URL from something
> like the following:
>
> url = git://davidfetter@git.postgresql.org/git/~davidfetter/postgresql/.git
>
> to
>
> url = git://davidfetter@git.postgresql.org/git/~davidfetter/with_recursive/.git
Let me try later.
> > This version implements:
> >
> > - detect certain queries those are not valid acroding to the standard
>
> Great :)
>
> > I also include erroneous query examples created by Yoshiyuki (probably
> > will become part of regression tests).
> >
> > Remaining problmes are:
> >
> > 1) sort query names acording to the dependency
>
> This can be done at query time already using arrays per Asaba-san's
> suggestion. I'll add some examples to the documentation.
1) refers to mutually recursive queres.
> > 2) planner always estimate 0 cost for recursion plans
> > 3) add regression tests
> >
> > For 1), I have proposed we limit query names to 1, in another word do
> > not allow mutually recursive queries. For 2) there's no good idea to
> > solve it, so I suggest leave it as it is now.
> >
> > For 3) I will generate regression tests as soon as possible.
> >
> > So the patches seem to be almost ready to commit IMO.
>
> Wonderful!
>
> Cheers,
> David.
> --
> David Fetter <david@fetter.org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david.fetter@gmail.com
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachments:
recursive_query.patch.gz (application/octet-stream, 25.0K) download
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-18 14:56 David Fetter <david@fetter.org>
parent: Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Fetter @ 2008-07-18 14:56 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
On Fri, Jul 18, 2008 at 10:41:20AM +0900, Tatsuo Ishii wrote:
> > > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> > > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
> >
> > I tried this patch vs. CVS HEAD used my usual configure option with
> > only --with-prefix set, then tried to make, and got:
> >
> > make[3]: *** No rule to make target `parse_cte.o', needed by `objfiles.txt'. Stop.
> > make[3]: Leaving directory `/home/shackle/pgsql/src/backend/parser'
> > make[2]: *** [parser-recursive] Error 2
> > make[2]: Leaving directory `/home/shackle/pgsql/src/backend'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory `/home/shackle/pgsql/src'
> > make: *** [all] Error 2
> >
> > Is there something missing?
>
> Oops. I forgot to include patches against newly added files. Please
> try included patches.
This now compiles.
I have a test case that hangs and smashes.
WITH t(i) AS (
SELECT * FROM generate_series(1,5)
)
SELECT
t1.i,
2*t2.i
FROM
t AS t1
JOIN
t AS t2 USING(i);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
An equivalent query without RECURSIVE breaks in a different, in some
sense even more severe, way, as in it just hands out a wrong result
set:
WITH RECURSIVE t(i) AS (
VALUES(1::int)
UNION ALL
SELECT i+1 FROM t WHERE i < 5
)
SELECT
t1.i,
2*t2.i
FROM
t AS t1
JOIN
t AS t2 USING(i);
i | ?column?
---+----------
1 | 2
2 | 4
3 | 6
4 | 8
5 | 10
(5 rows)
While this case is trivial, others are not. For example, if someone
wishes to do a k-deep summary on a parts explosion n levels deep, n>k,
one way to do this would be to JOIN the k-deep part of the path
enumeration to the parts greater than k deep.
What would need to be fixed in order to make the above things work?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-18 15:13 David Fetter <david@fetter.org>
parent: David Fetter <david@fetter.org>
0 siblings, 0 replies; 11+ messages in thread
From: David Fetter @ 2008-07-18 15:13 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
On Fri, Jul 18, 2008 at 07:56:09AM -0700, David Fetter wrote:
> On Fri, Jul 18, 2008 at 10:41:20AM +0900, Tatsuo Ishii wrote:
> > > > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> > > > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
> > >
> > > I tried this patch vs. CVS HEAD used my usual configure option with
> > > only --with-prefix set, then tried to make, and got:
> > >
> > > make[3]: *** No rule to make target `parse_cte.o', needed by `objfiles.txt'. Stop.
> > > make[3]: Leaving directory `/home/shackle/pgsql/src/backend/parser'
> > > make[2]: *** [parser-recursive] Error 2
> > > make[2]: Leaving directory `/home/shackle/pgsql/src/backend'
> > > make[1]: *** [all] Error 2
> > > make[1]: Leaving directory `/home/shackle/pgsql/src'
> > > make: *** [all] Error 2
> > >
> > > Is there something missing?
> >
> > Oops. I forgot to include patches against newly added files. Please
> > try included patches.
>
> This now compiles.
>
> I have a test case that hangs and smashes.
>
> WITH t(i) AS (
> SELECT * FROM generate_series(1,5)
> )
> SELECT
> t1.i,
> 2*t2.i
> FROM
> t AS t1
> JOIN
> t AS t2 USING(i);
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> An equivalent query without RECURSIVE breaks in a different, in some
> sense even more severe, way, as in it just hands out a wrong result
> set:
D'oh! That's what I get for sending this before waking up. It works
just fine.
> While this case is trivial, others are not. For example, if someone
> wishes to do a k-deep summary on a parts explosion n levels deep,
> n>k, one way to do this would be to JOIN the k-deep part of the path
> enumeration to the parts greater than k deep.
>
> What would need to be fixed in order to make the above things work?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-18 17:30 Erik <er@xs4all.nl>
0 siblings, 1 reply; 11+ messages in thread
From: Erik @ 2008-07-18 17:30 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
On Fri, July 18, 2008 03:41, Tatsuo Ishii wrote:
>> > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
>> > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
>>
>> I tried this patch vs. CVS HEAD used my usual configure option with
>> only --with-prefix set, then tried to make, and got:
>>
>> make[3]: *** No rule to make target `parse_cte.o', needed by `objfiles.txt'.
>> Stop.
>> make[3]: Leaving directory `/home/shackle/pgsql/src/backend/parser'
>> make[2]: *** [parser-recursive] Error 2
>> make[2]: Leaving directory `/home/shackle/pgsql/src/backend'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/home/shackle/pgsql/src'
>> make: *** [all] Error 2
>>
>> Is there something missing?
>
> Oops. I forgot to include patches against newly added files. Please
> try included patches.
>
This crashes the backend:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n < 5 ORDER BY 1
)
SELECT n FROM t;
apparently because of the ORDER BY 1
( ORDER BY t.n will just error out )
Compiled with:
./configure \
--prefix=${install_dir} \
--with-pgport=${pgport} \
--quiet \
--enable-depend \
--enable-cassert \
--enable-debug \
--with-openssl
hth
Erik Rijkers
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-20 15:42 Tatsuo Ishii <ishii@postgresql.org>
parent: Erik <er@xs4all.nl>
0 siblings, 1 reply; 11+ messages in thread
From: Tatsuo Ishii @ 2008-07-20 15:42 UTC (permalink / raw)
To: er@xs4all.nl; +Cc: ishii@postgresql.org; pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
> This crashes the backend:
>
> WITH RECURSIVE t(n) AS (
> VALUES (1)
> UNION ALL
> SELECT n+1 FROM t WHERE n < 5 ORDER BY 1
> )
> SELECT n FROM t;
>
> apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES (1) UNION ALL SELECT n+1 FROM t WHERE
n < 5). Since this is a recursive query, value for (VALUES (1) UNION
ALL SELECT n+1 FROM t WHERE n < 5) will not be determined until the
recursion stops. So the meaning of ORDER BY is vague. If caller wants
to get the sorted result of the recursion, he could always write:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n < 5
)
SELECT n FROM t ORDER BY 1;
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well. Included patches add the
checking plus minor error messages clarifications. Also I include new
error cases sql.
> ( ORDER BY t.n will just error out )
>
> Compiled with:
>
> ./configure \
> --prefix=${install_dir} \
> --with-pgport=${pgport} \
> --quiet \
> --enable-depend \
> --enable-cassert \
> --enable-debug \
> --with-openssl
>
>
> hth
>
> Erik Rijkers
>
>
>
>
>
Attachments:
error.sql (text/plain, 2.2K) download
-- UNION
WITH RECURSIVE x(n) AS (SELECT 1 UNION SELECT n+1 FROM x)
SELECT * FROM x;
-- INTERSECT
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- EXCEPT
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- no non-recursive term
WITH RECURSIVE x(n) AS (SELECT n FROM x)
SELECT * FROM x;
-- recursive term in the left hand side
WITH RECURSIVE x(n) AS (SELECT n FROM x UNION ALL SELECT 1)
SELECT * FROM x;
CREATE TEMP TABLE y (a int);
INSERT INTO y SELECT generate_series(1, 10);
-- LEFT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM y LEFT JOIN x ON x.n = y.a where n < 10)
SELECT * FROM x;
-- RIGHT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM x RIGHT JOIN y ON x.n = y.a where n < 10)
SELECT * FROM x;
-- FULL JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM x FULL JOIN y ON x.n = y.a where n < 10)
SELECT * FROM x;
-- subquery
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n IN (SELECT * FROM x))
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n = 1 AND n IN (SELECT * FROM x))
SELECT * FROM x;
-- GROUP BY
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x GROUP BY n)
SELECT * FROM x;
-- HAVING
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x HAVING n < 10)
SELECT * FROM x;
-- aggregate functions
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT count(*) FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT sum(*) FROM x)
SELECT * FROM x;
-- ORDER BY
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x ORDER BY 1)
SELECT * FROM x;
-- LIMIT/OFFSET
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x LIMIT 10 OFFSET 1)
SELECT * FROM x;
-- FOR UPDATE
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x FOR UPDATE)
SELECT * FROM x;
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-20 16:22 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2008-07-20 16:22 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: er@xs4all.nl; pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.org> writes:
> Thus I think we should avoid this kind of ORDER BY. Probably we should
> avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-20 23:19 Tatsuo Ishii <ishii@postgresql.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Tatsuo Ishii @ 2008-07-20 23:19 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: ishii@postgresql.org; er@xs4all.nl; pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
> > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > avoid LIMIT/OFFSET and FOR UPDATE as well.
>
> What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
standard. For example,
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x)
SELECT * FROM x;
produces an error.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-21 00:00 David Fetter <david@fetter.org>
parent: Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Fetter @ 2008-07-21 00:00 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: tgl@sss.pgh.pa.us; er@xs4all.nl; pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
> > > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > > avoid LIMIT/OFFSET and FOR UPDATE as well.
> >
> > What of index-optimized SELECT max(...) ?
>
> Aggregate functions in a recursive term is prohibited by the
> standard. For example,
>
> WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x)
> SELECT * FROM x;
>
> produces an error.
On the other side of UNION ALL, it's OK, right? For example,
WITH RECURSIVE x(n) AS (
SELECT max(i) FROM t
UNION ALL
SELECT n+1 FROM x WHERE n < 20
)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [PATCHES] WITH RECUSIVE patches 0717
@ 2008-07-21 01:13 Tatsuo Ishii <ishii@postgresql.org>
parent: David Fetter <david@fetter.org>
0 siblings, 0 replies; 11+ messages in thread
From: Tatsuo Ishii @ 2008-07-21 01:13 UTC (permalink / raw)
To: david@fetter.org; +Cc: ishii@postgresql.org; tgl@sss.pgh.pa.us; er@xs4all.nl; pgsql-patches; pgsql-hackers@postgresql.org; y-asaba@sraoss.co.jp
> On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
> > > > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > > > avoid LIMIT/OFFSET and FOR UPDATE as well.
> > >
> > > What of index-optimized SELECT max(...) ?
> >
> > Aggregate functions in a recursive term is prohibited by the
> > standard. For example,
> >
> > WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x)
> > SELECT * FROM x;
> >
> > produces an error.
>
> On the other side of UNION ALL, it's OK, right? For example,
>
> WITH RECURSIVE x(n) AS (
> SELECT max(i) FROM t
> UNION ALL
> SELECT n+1 FROM x WHERE n < 20
> )
Yes, aggregate functions in the non-recursive term is allowed by the
standard.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2008-07-21 01:13 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-07-17 09:40 WITH RECUSIVE patches 0717 Tatsuo Ishii <ishii@postgresql.org>
2008-07-17 16:01 ` David Fetter <david@fetter.org>
2008-07-18 01:41 ` Tatsuo Ishii <ishii@postgresql.org>
2008-07-18 14:56 ` David Fetter <david@fetter.org>
2008-07-18 15:13 ` David Fetter <david@fetter.org>
2008-07-18 17:30 Re: [PATCHES] WITH RECUSIVE patches 0717 Erik <er@xs4all.nl>
2008-07-20 15:42 ` Tatsuo Ishii <ishii@postgresql.org>
2008-07-20 16:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2008-07-20 23:19 ` Tatsuo Ishii <ishii@postgresql.org>
2008-07-21 00:00 ` David Fetter <david@fetter.org>
2008-07-21 01:13 ` Tatsuo Ishii <ishii@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox