Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote: No idea. What do you think if we allow only one query name at the moment. I'm not sure I understand what that has to do with sorting. Please find attached a place where I've found some problems sorting by tree by array as Asaba-san suggested. Humm. your problem seems to do nothing with the problem I refer to. Sorry about that. Is my problem reproducible? Is there maybe some way to include regression tests around it? According to Asaba, it's not a bug with recursive query. In another word, the query result you are getting is the expected one. Asaba? What I have in my mind is something like: WITH RECURSIVE foo(a, b) AS (SELECT ... UNION SELECT...), bar(c, d) AS (SELECT ... FROM foo WHERE ...UNION...) ) SELECT * FROM foo; In this there are two query names (foo, bar) and we need to detect the dependency that bar relies on foo before processing the query. I think mutually recursive queries may have been dropped from SQL:2008. I'm pretty sure that SQL:2008 has mutually recursive queries(I have the final draft of SQL:2008 here). However, as I said earlier, this kind of use case would be rare in the real world, and I'd like to limit ourselves to having only one query name at the moment. Also I suggest to concentrate on reviewing the WITH RECURSIVE implementation itself now, rather than discussing how to use git repository or how to write an interesting WITH RECURSIVE applications. Don't get me wrong. I believe git is a great tool. But we have limited time and need to think about the priority. Fair enough :) Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Great! I've patched psql for some partial support of WITH [RECURSIVE]. http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 Thanks. I will incorporate them with propsed patches. Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency Is there something in the standard on how to do this? How to sort the nodes other ways? No idea. What do you think if we allow only one query name at the moment. I guess most WITH RECURISVE use cases are enough with single query name. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote:
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
Here is the patches he made against CVS HEAD (as of today).
According to him followings are fixed with the patches:
- fix crush with DISTINCT
- fix creating VIEW
- fix the case when recursion plan has another recursion plan under it
- fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result
- fix inifinit recursion with OUTER JOIN
Great!
I've patched psql for some partial support of WITH [RECURSIVE].
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793
Thanks. I will incorporate them with propsed patches.
Part of the point of this exercise is to make git the way to do this.
Can you please point me to a git repository where your latest changes
are so I can publish them?
Not yet fixed:
- detect certain queries those are not valid acroding to the standard
- sort query names acording to the dependency
Is there something in the standard on how to do this? How to sort
the nodes other ways?
No idea. What do you think if we allow only one query name at the
moment.
I'm not sure I understand what that has to do with sorting.
Please find attached a place where I've found some problems sorting by
tree by array as Asaba-san suggested.
Cheers,
David.
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: [EMAIL PROTECTED]
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
CREATE TABLE region (
region_id SERIAL PRIMARY KEY,
region_name TEXT NOT NULL,
region_type TEXT NOT NULL,
parent_region_id INTEGER REFERENCES region(region_id),
CHECK (
CASE WHEN region_type = 'Country' THEN 1 ELSE 0 END +
CASE WHEN parent_region_id IS NULL THEN 0 ELSE 1 END = 1
)
);
CREATE UNIQUE INDEX country_top_idx
ON region(region_name) WHERE region_type = 'Country';
CREATE UNIQUE INDEX must_have_parents_idx ON
region(region_name, region_type, parent_region_id)
WHERE parent_region_id IS NOT NULL;
INSERT INTO region (region_name, region_type)
VALUES
('Brasil', 'Country'),
('United States', 'Country');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Centro-Oeste','Região'),
('Nordeste','Região'),
('Norte','Região'),
('Sudeste','Região'),
('Sul','Região')
) AS v
WHERE (r.region_name, r.region_type) = ('Brasil','Country');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Goiás','Estado'),
('Mato Grosso','Estado'),
('Mato Grosso do Sul','Estado'),
('Distrito Federal','Distrito Federal')
) AS v
WHERE (r.region_name, r.region_type) = ('Centro-Oeste','Região');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Maranhão','Estado'),
('Piauí','Estado'),
('Ceará','Estado'),
('Rio Grande do Norte','Estado'),
('Paraíba','Estado'),
('Pernambuco','Estado'),
('Alagoas','Estado'),
('Sergipe','Estado'),
('Bahia','Estado')
) AS v
WHERE (r.region_name, r.region_type) = ('Nordeste','Região');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Acre','Estado'),
('Amazonas','Estado'),
('Roraima','Estado'),
('Rondônia','Estado'),
('Pará','Estado'),
('Amapá','Estado'),
('Tocantins','Estado')
) AS v
WHERE (r.region_name, r.region_type) = ('Norte','Região');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Minas Gerais','Estado'),
('Espírito Santo','Estado'),
('Rio de Janeiro','Estado'),
('São Paulo','Estado')
) AS v
WHERE (r.region_name, r.region_type) = ('Sudeste','Região');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Paraná','Estado'),
('Santa Catarina','Estado'),
('Rio Grande do Sul','Estado')
) AS v
WHERE (r.region_name, r.region_type) = ('Sul','Região');
INSERT INTO region (parent_region_id, region_name, region_type)
SELECT r.region_id, v.*
FROM
region r
CROSS JOIN
(
VALUES
('Goiânia','Cidade'),
('Aparecida de Goiânia','Cidade'),
('Anápolis','Cidade'),
('Luziânia','Cidade'),
('Águas Lindas de Goiás','Cidade'),
('Rio Verde','Cidade'),
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote: On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Great! I've patched psql for some partial support of WITH [RECURSIVE]. http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 Thanks. I will incorporate them with propsed patches. Part of the point of this exercise is to make git the way to do this. Can you please point me to a git repository where your latest changes are so I can publish them? Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency Is there something in the standard on how to do this? How to sort the nodes other ways? No idea. What do you think if we allow only one query name at the moment. I'm not sure I understand what that has to do with sorting. Please find attached a place where I've found some problems sorting by tree by array as Asaba-san suggested. Humm. your problem seems to do nothing with the problem I refer to. What I have in my mind is something like: WITH RECURSIVE foo(a, b) AS (SELECT ... UNION SELECT...), bar(c, d) AS (SELECT ... FROM foo WHERE ...UNION...) ) SELECT * FROM foo; In this there are two query names (foo, bar) and we need to detect the dependency that bar relies on foo before processing the query. However, as I said earlier, this kind of use case would be rare in the real world, and I'd like to limit ourselves to having only one query name at the moment. Also I suggest to concentrate on reviewing the WITH RECURSIVE implementation itself now, rather than discussing how to use git repository or how to write an interesting WITH RECURSIVE applications. Don't get me wrong. I believe git is a great tool. But we have limited time and need to think about the priority. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote: No idea. What do you think if we allow only one query name at the moment. I'm not sure I understand what that has to do with sorting. Please find attached a place where I've found some problems sorting by tree by array as Asaba-san suggested. Humm. your problem seems to do nothing with the problem I refer to. Sorry about that. Is my problem reproducible? Is there maybe some way to include regression tests around it? What I have in my mind is something like: WITH RECURSIVE foo(a, b) AS (SELECT ... UNION SELECT...), bar(c, d) AS (SELECT ... FROM foo WHERE ...UNION...) ) SELECT * FROM foo; In this there are two query names (foo, bar) and we need to detect the dependency that bar relies on foo before processing the query. I think mutually recursive queries may have been dropped from SQL:2008. However, as I said earlier, this kind of use case would be rare in the real world, and I'd like to limit ourselves to having only one query name at the moment. Also I suggest to concentrate on reviewing the WITH RECURSIVE implementation itself now, rather than discussing how to use git repository or how to write an interesting WITH RECURSIVE applications. Don't get me wrong. I believe git is a great tool. But we have limited time and need to think about the priority. Fair enough :) Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Great! I've patched psql for some partial support of WITH [RECURSIVE]. http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency Is there something in the standard on how to do this? How to sort the nodes other ways? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote: David Fetter wrote: On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). The git repository should now match this :) http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary Apparently, it's easiest to clone via the following URL: http://git.postgresql.org/git/~davidfetter/postgresql/.git Is there some git repository I can pull from to make this a little less manual? In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... It's *very* early days to be dismissing git entirely. We don't have auths fixed up yet, and I contend that that's because the people who have sudo on the git machine are unwilling to create git-shell accounts for people who need them. If I get sudo access, I'll be delighted to do that stuff. There's another issue people seem to keep trying to sneak into this discussion, which is creating a high-value target for attackers, aka single sign-on. We really need to have a separate discussion of single sign-on and not hold up every infrastructure project while waiting for a feature that it is far from clear that we should even have in the first place. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
* David Fetter [EMAIL PROTECTED] [080709 14:45]: On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote: In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... It's *very* early days to be dismissing git entirely. We don't have auths fixed up yet, and I contend that that's because the people who have sudo on the git machine are unwilling to create git-shell accounts for people who need them. I don't think that was intended to dismiss git entirely, but only question what the point of this particular git repo/branch is for: http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive Is it just to provide an alternative way to fetch the patch? I would have thought that anybody who can compile PostgreSQL from source can apply a patch (if the patch available and applies cleanly). The with_recursive branch doesn't seem to provide any of the nice goodies that git could provide (i.e. patch history, merge corresponding to various versions so you can easily see what changed, etc) a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Wed, Jul 09, 2008 at 04:43:27PM -0400, Aidan Van Dyk wrote: * David Fetter [EMAIL PROTECTED] [080709 14:45]: On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote: In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... It's *very* early days to be dismissing git entirely. We don't have auths fixed up yet, and I contend that that's because the people who have sudo on the git machine are unwilling to create git-shell accounts for people who need them. I don't think that was intended to dismiss git entirely, but only question what the point of this particular git repo/branch is for: http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive Is it just to provide an alternative way to fetch the patch? I would have thought that anybody who can compile PostgreSQL from source can apply a patch (if the patch available and applies cleanly). The with_recursive branch doesn't seem to provide any of the nice goodies that git could provide (i.e. patch history, merge corresponding to various versions so you can easily see what changed, etc) I'm really new to this git thing, but I now have access to create git-shell accounts, etc. on git.postgresql.org. Any ideas you can offer on how better to handle this would really help me. :) Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency - planner always estimate 0 cost for recursion plans -- Tatsuo Ishii SRA OSS, Inc. Japan - SQL:2008 に規定されているクエリ以外をエラーにする処理 - 依存関係の順番で評価するようにする仕組み - プランナが常にコスト 0 で見積る On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote: Hi, test=# explain select count(*) test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT DISTINCT n+1 FROM t ) test(# SELECT * FROM t WHERE n 50) as t test-# WHERE n 100; 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. ! \q this one will kill the planner :( removing the (totally stupid) distinct avoids the core dump. Thanks. I've fixed on local repository. Asaba-san, do you have a patch against CVS HEAD or against the previous one? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate recursive_query-8.patch.bz2 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). The git repository should now match this :) http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary Apparently, it's easiest to clone via the following URL: http://git.postgresql.org/git/~davidfetter/postgresql/.git Is there some git repository I can pull from to make this a little less manual? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
David Fetter wrote: On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: Here is the patches he made against CVS HEAD (as of today). The git repository should now match this :) http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary Apparently, it's easiest to clone via the following URL: http://git.postgresql.org/git/~davidfetter/postgresql/.git Is there some git repository I can pull from to make this a little less manual? In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Hi, From: Hans-Juergen Schoenig [EMAIL PROTECTED] Subject: Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP Date: Sat, 5 Jul 2008 10:43:57 +0200 i did some quick testing with this wonderful patch. it seems there are some flaws in there still: test=# explain select count(*) test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT DISTINCT n+1 FROM t ) test(# SELECT * FROM t WHERE n 50) as t test-# WHERE n 100; 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. ! \q this one will kill the planner :( removing the (totally stupid) distinct avoids the core dump. Thanks. I've fixed on local repository. i found one more issue; -- broken: wrong result test=# select count(*) from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM t) SELECT * FROM t WHERE n 50) as t WHERE n ( select count(*) from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM t ) SELECT * FROM t WHERE n 50) as t WHERE n 100) ; I've fixed. However, this query enters infinite loop. WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM t) SELECT * FROM t WHERE n 50 The planner distributed WHERE-clause into WITH-clause with previous recursive-patch. WITH RECURSIVE t(n) AS ( SELECT 1 WHERE n 50 UNION ALL SELECT n + 1 FROM t WHERE n 50) SELECT * FROM t; This optimization is in qual_is_pushdown_safe(). So, I've fixed not to optimize WITH-clause in the function. Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] if i am not totally wrong, this should give us a different result. i am looking forward to see this patch in core :). it is simply wonderful ... many thanks, hans On Jul 3, 2008, at 1:11 AM, David Fetter wrote: Folks, Please find patch enclosed, including some documentation. Can we see about getting this in this commitfest? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/ donaterecursive_query-7.patch.bz2 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote: Hi, test=# explain select count(*) test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT DISTINCT n+1 FROM t ) test(# SELECT * FROM t WHERE n 50) as t test-# WHERE n 100; 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. ! \q this one will kill the planner :( removing the (totally stupid) distinct avoids the core dump. Thanks. I've fixed on local repository. Asaba-san, do you have a patch against CVS HEAD or against the previous one? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
