So to implement recursive queries I think what we need is a memoizing node
like Materialize which allows multiple simultaneous readers.
Looking into how to implement this I find that the read position of a
Materialize node is actually implemented directly in tuplestore.c.
That means that
The CONNECT BY patch from evgen potemkin has been ported to pg 8.2...
and it's now in BSD License...
I will test it on our test environement
Le jeudi 25 janvier 2007 à 11:08 +, Gregory Stark a écrit :
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite different from what I was expecting. My own thinking was headed off
in a different direction.
Basically the existing patch reimplements a new kind of join which implements
a kind of nested loop join (with
Ühel kenal päeval, N, 2007-01-25 kell 11:08, kirjutas Gregory Stark:
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite different from what I was expecting. My own thinking was headed off
in a different direction.
Basically the existing patch reimplements
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure how
to reconcile that with the repeated-join conceptual model. We could always
resort the entire result set after generating it but that seems like an
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure
how
to reconcile that with the repeated-join conceptual model. We could always
resort the entire result
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure
how
to reconcile that with the repeated-join conceptual model. We could always
Joshua D. Drake [EMAIL PROTECTED] writes:
That's basically how the existing patch approached the problem. It invents a
new type of join and a new type of tuplestore that behaves this way. This
has
the advantage of working the way Oracle users expect and being relatively
simple
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen Potemkin?
I have some ideas myself for how to go about
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Yes your co-employee Jonah.
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00989.php
Sincerely,
Joshua D. Drake
--
=== The
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen Potemkin?
I have some ideas
Andrew Dunstan wrote:
Gregory Stark wrote:
I'm looking into recursive queries and what it would take to support them in
Postgres. Is anyone else looking at this already?
Aside from the Oracle-ish syntax were there other objections to the patch as
posted a while back for 7.3 by Evgen
Bruce Momjian wrote:
Wasn't somebody else working on this? Jonah? (Maybe you EDB guys need to
talk more ...)
He is taking it over for Jonah.
Oh, good. That was the piece of missing info. I had a case just
yesterday where this feature would have saved us hours of writing client
The only code that is usable (and performant) is the CONNECT BY patch
made by Evgen Potemkin, It works on production servers on the 8.1.5
I hope that a WITH RECURSIVE will be in the 8.3... but I don't see
anybody working on this... (what a shame...)
Le mercredi 24 janvier 2007 à 17:27 +,
Michael Meskes wrote:
Just wanted to let you know that if we would be interested in adding
that patch to our main cvs the guy who wrote it would be more than
willing to change his license to BSD.
I was under the impression we wanted to implement the ANSI way to do
this. Is this what the patch
hi again,
at last i found patch for WITH and make it working.
it's resides in attach.
what it does:
WITH a AS (SELECT * FROM t) SELECT * FROM a;
WITH a AS (SELECT * FROM t), b as (SELECT * FROM t) SELECT * FROM
a.id=b.id;
WITH a AS (SELECT * FROM t), b AS (SELECT * FROM a) SELECT * FROM b;
Just wanted to let you know that if we would be interested in adding
that patch to our main cvs the guy who wrote it would be more than
willing to change his license to BSD.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL
hello hackers,
some time ago i played with PgSQL and have written simpliest working
prototype of WITH clause for it.
it don't do any checks and performs only simpliest selects, but it works.
i can contribute it and develop it further to production state.
regards,
.evgen
Christopher Kings-Lynne wrote:
There is a website somewhere where a guy posts his patch he is
maintaining that does it. I'll try to find it...
Found it. Check it out:
http://gppl.terminal.ru/index.eng.html
Patch is current for 7.4, Oracle syntax.
Chris
I had a look at the patch.
It is
I haven't had any problems with it so far, although I haven't really
stressed it yet. I was going to make this very plea...
I agree that the syntax can probably be improved, but its familiar to
those of us unfortunate enough to have used (or still have to use)
Oracle. I imagine that bringing
Clinging to sanity, [EMAIL PROTECTED] (Andrew Rawnsley) mumbled into her beard:
I haven't had any problems with it so far, although I haven't really
stressed it yet. I was going to make this very plea...
I agree that the syntax can probably be improved, but its familiar to
those of us
On Wed, 2004-02-04 at 05:28, Hans-Jürgen Schönig wrote:
Christopher Kings-Lynne wrote:
There is a website somewhere where a guy posts his patch he is
maintaining that does it. I'll try to find it...
Found it. Check it out:
http://gppl.terminal.ru/index.eng.html
Patch is
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Does this patch have a serious chance to make it into Pg some day?
I think Oracle's syntax is not perfect but is easy to handle and many
people are used to it. In people's mind recursive queries = CONNECT BY
and many people
Robert Treat kirjutas K, 04.02.2004 kell 16:55:
Seems it has no chance of getting in as it is GPL'd code... so step one
would be convincing him to relicense it.
As a side note, I thought Joe Conway also had an implementation of
this...
IIRC Joe Conway had the simple join-by-parent-id
Tom Lane kirjutas K, 04.02.2004 kell 06:04:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Wasn't there some guy at RedHat doing it?
Andrew Overholt did some work on SQL99 recursive queries, but went back
to university without having gotten to the point where it actually
worked. One of
Christopher Browne kirjutas K, 04.02.2004 kell 15:10:
The fact that the form of this resembles that of the Lisp/ML let
forms means that WITH can be useful in structuring queries as well.
For instance, supposing you're computing a value that gets used
several times, putting it into a WITH
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Does this patch have a serious chance to make it into Pg some day?
I think Oracle's syntax is not perfect but is easy to handle and many
people are used to it. In people's mind recursive queries = CONNECT BY
and
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
In my very personal opinion (don't cut my head off) I'd vote for both
syntaxes.
I'm not opposed to that, although it would be a good idea to check that
Oracle doesn't have some patent covering their syntax.
However, if we go
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Wasn't there some guy at RedHat doing it?
Andrew Overholt did some work on SQL99 recursive queries, but went back
to university without having gotten to the point where it actually
worked. One of the many things on my to-do list is to pick up
Andrew Overholt did some work on SQL99 recursive queries, but went back
to university without having gotten to the point where it actually
worked. One of the many things on my to-do list is to pick up and
finish Andrew's work on this. If someone has time to work on it,
let me know and I'll try
There is a website somewhere where a guy posts his patch he is
maintaining that does it. I'll try to find it...
Found it. Check it out:
http://gppl.terminal.ru/index.eng.html
Patch is current for 7.4, Oracle syntax.
Chris
---(end of
Tom Lane once said:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Andrew Overholt of Red Hat has been working
on this, but is certainly not going to make the Tuesday feature-freeze
deadline.
I was just wondering who was working on it and what the progress was...? It
seemed to me
What's the chances of getting recursive queries in for 7.4?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What's the chances of getting recursive queries in for 7.4?
If you mean SQL99 WITH clauses, approximately zero ... unless you
had an implementation you were planning to whip out of your hip
pocket along about now. Andrew Overholt of Red Hat has
If you mean SQL99 WITH clauses, approximately zero ... unless you
had an implementation you were planning to whip out of your hip
pocket along about now. Andrew Overholt of Red Hat has been working
on this, but is certainly not going to make the Tuesday feature-freeze
deadline.
I was just
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Andrew Overholt of Red Hat has been working
on this, but is certainly not going to make the Tuesday feature-freeze
deadline.
I was just wondering who was working on it and what the progress was...? It
seemed to me that it must have been
36 matches
Mail list logo
