David Fetter <[EMAIL PROTECTED]> writes:
> How hard would it be to add the infrastructure for CYCLE?
Personally I'm more interested in getting the recursive UNION (without
ALL) case to work.
I think that this might just be a matter of drawing on support that's
already there: have RecursiveUnion m
On Fri, Oct 03, 2008 at 03:55:56PM -0400, Tom Lane wrote:
> I've successfully taught the WITH patch to do single evaluation of
> WITH queries. I've also been through all of the planner and
> executor code for it and am now feeling pretty happy with the whole
> thing. There are still a small numbe
2008/10/2 Greg Stark <[EMAIL PROTECTED]>:
>
>
> On 2 Oct 2008, at 05:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>>
>>> Hmm, I've looked over the patch. Logically window functions can access
>>> arbitrary rows that have been stored in a frame. Thus I
On 2 Oct 2008, at 05:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
Hmm, I've looked over the patch. Logically window functions can
access
arbitrary rows that have been stored in a frame. Thus I had thought
tuplestore should hold all the positions a
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/10/2 Tom Lane <[EMAIL PROTECTED]>:
>> Okay, there's a patch in CVS HEAD that works this way. Let me know if
>> it needs further tweaking for your purposes.
> Hmm, I've looked over the patch. Logically window functions can access
> arbitrary rows
2008/10/2 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>>> I hadn't realized that this would be relevant to window functions.
>>> Now that I know that, I propose fixing tuplestore for multiple
>>> positions and committing it separately, before I go back to the CTE
>>
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> I hadn't realized that this would be relevant to window functions.
>> Now that I know that, I propose fixing tuplestore for multiple
>> positions and committing it separately, before I go back to the CTE
>> patch. Then Hitoshi-san will have something
>> One other reason the tuplestore should know the position of all the
>> readers is that ideally it would want to be able to discard any tuples
>> older than the oldest read position. That also means it needs to know
>> when all the call sites have allocated their position and don't need
>> to res
On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So it seems like the appropriate generalization is to have an array of
> read positions inside the tuplestore and allow callers to say "read
> using position N", plus some API to allow positions to be allocated to
> different req
"Greg Stark" <[EMAIL PROTECTED]> writes:
> On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So it seems like the appropriate generalization is to have an array of
>> read positions inside the tuplestore and allow callers to say "read
>> using position N", plus some API to allo
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> It seems to me to share some ideas with the MemoryContext concept: what
>> about a TupstoreContext associated with tuplestore, you get a common default
>> one if you don't register your own, and use
>> tuplestore_gettuple(MyTupstoreContext, ...);
> I
Hi,
2008/10/1 Dimitri Fontaine <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Le 30 sept. 08 à 20:03, Tom Lane a écrit :
>>
>>set_read_position(tupstore, &local_read_position);
>>tuple = tuplestore_gettuple(tupstore, ...);
>>get_read_posi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 30 sept. 08 à 20:03, Tom Lane a écrit :
set_read_position(tupstore, &local_read_position);
tuple = tuplestore_gettuple(tupstore, ...);
get_read_position(tupstore, &local_read_position);
rather than just tuplestore_get
Greg Stark <[EMAIL PROTECTED]> writes:
> On 24 Sep 2008, at 02:45, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The next big
>> thing seems to be to figure out exactly how to do multiple references
>> to CTE outputs, so that we can de-bogotify the planner.
> I've looked and don't seem to still have the
Tom,
> > WithClause node may need a location field, and almost certainly has to
> > be handled somehow in exprLocation().
> >
> > The error reports in parse_cte.c *desperately* need error locations.
Included is a patch for this against your cte-0923.patch.gz. Most
errors now have error locations
greg
On 24 Sep 2008, at 02:45, Tom Lane <[EMAIL PROTECTED]> wrote:
The next big
thing seems to be to figure out exactly how to do multiple references
to CTE outputs, so that we can de-bogotify the planner.
I've looked and don't seem to still have the source tree where I
worked on this. I r
I am re-sending this message to -hackers from yesterday, because the
first time it didn't appear to make it through. This time I gzipped the
patch. This is just for the archives (and to give context to the
replies), and this message is superseded by Tom's patch here:
http://archives.postgresql.org
Attached is the result of a couple of days hacking on the WITH RECURSIVE
patch. This moves us a lot closer to having sanity in the parsing
phase, though I'm still quite unhappy with the second half of the
processing in parse_cte.c. I added some infrastructure to make the
first half's search for C
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Yeah, I'd been running into that issue too. Adding an explicit pointer
>> to the CTE into the RTE doesn't work because it renders the parse tree
>> un-copiable (at least without something a lot more sophisticated t
Tom Lane <[EMAIL PROTECTED]> writes:
> Yeah, I'd been running into that issue too. Adding an explicit pointer
> to the CTE into the RTE doesn't work because it renders the parse tree
> un-copiable (at least without something a lot more sophisticated than
> copyObject; and saving/loading rule pars
Jeff Davis <[EMAIL PROTECTED]> writes:
> Here is a patch that is an initial attempt to reorganize the parse tree
> representation.
Oh dear, we seem to have spent yesterday doing the same work :-(
I'll go over this and try to merge it with my own WIP.
> * There are a couple of other rough points
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> PlanState.has_recursivescan seems like a complete kluge. Can't it just be
>> removed? It looks to me like it is working around bugs that hopefully aren't
>> there anymore. There is certainly no reason why a recursive CTE should be
>> more in need of re
> PlanState.has_recursivescan seems like a complete kluge. Can't it just be
> removed? It looks to me like it is working around bugs that hopefully aren't
> there anymore. There is certainly no reason why a recursive CTE should be
> more in need of rescanning than any other kind of plan.
I don'
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Why does set_recursion_pathlist think that the subquery might have
>> useful pathkeys? We know it must always be a UNION ALL, no?
> Right. But someday we might implement "UNION" (without ALL) then we
> have useful pathkeys...
Good point. Might as well
> Why does set_recursion_pathlist think that the subquery might have
> useful pathkeys? We know it must always be a UNION ALL, no?
Right. But someday we might implement "UNION" (without ALL) then we
have useful pathkeys...
Or shall I completely remove the step to generate patheys and do not
pass
Tom, thanks for the review.
Here is an in-progress report. Patches against CVS HEAD attached.
(uncommented items are work-in-progress).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Included is the latest patches against CVS HEAD.
>
> I spent some time readin
> > To enable physical_tlist optimization, it seems build_physical_tlist,
> > use_physical_tlist and disuse_physical_tlist need to be
> > changed. build_physical_tlist and use_physical_tlist have been already
> > patched and only disuse_physical_tlist needs to be patched. Any other
> > place I miss
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Is physical_tlist optimization sensible for RecursiveScan? We seem
>> to use it for every other Scan node type.
> To enable physical_tlist optimization, it seems build_physical_tlist,
> use_physical_tlist and disuse_physical_tlist need to be
> changed.
> Is physical_tlist optimization sensible for RecursiveScan? We seem
> to use it for every other Scan node type.
To enable physical_tlist optimization, it seems build_physical_tlist,
use_physical_tlist and disuse_physical_tlist need to be
changed. build_physical_tlist and use_physical_tlist have
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>>> I am not sure, if these rule is good. Somebody who develop on
>>> postgresql should have a problems when they will be port to other
>>> databases in future. Reserved words in standards should be
respected.
>
>
"Robert Haas" <[EMAIL PROTECTED]> writes:
>> I am not sure, if these rule is good. Somebody who develop on
>> postgresql should have a problems when they will be port to other
>> databases in future. Reserved words in standards should be respected.
> I disagree. I have never ported an app written
> I am not sure, if these rule is good. Somebody who develop on
> postgresql should have a problems when they will be port to other
> databases in future. Reserved words in standards should be respected.
I disagree. I have never ported an app written for PostgreSQL to
another database system, and
2008/9/17 Tom Lane <[EMAIL PROTECTED]>:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>>> Do we really have to make RECURSIVE a fully reserved keyword?
>
>> According to the standard, RECURSIVE is a reserved keyword, I believe.
>
> Sure, but our general rule is to make keywords no more reserved than
>
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Do we really have to make RECURSIVE a fully reserved keyword?
> According to the standard, RECURSIVE is a reserved keyword, I believe.
Sure, but our general rule is to make keywords no more reserved than
is absolutely necessary to make the bison grammar
> Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
> (Actually, the patch makes it worse than reserved, by failing to
> add it to the reserved_keywords list.)
Yes, it's a bug. Will fix...
--
Tatsuo Ishii
SRA OSS,
Greg Stark <[EMAIL PROTECTED]> writes:
> I had either on that a while back. I think the existing tuplestore can
> be made to work without bad performance penaltiesbin the usual case.
> The trick was to do it without making the code unreadable.
> I can send the code I had but I doubt you want t
I had either on that a while back. I think the existing tuplestore can
be made to work without bad performance penaltiesbin the usual case.
The trick was to do it without making the code unreadable.
I can send the code I had but I doubt you want to use it as-is.
--
greg
--
Sent via pgsql-h
Jeff Davis <[EMAIL PROTECTED]> writes:
> I think the right approach is to try to complete it so that everyone is
> happy. I will work on this, but unfortunately I don't have a lot of time
> right now, so I can't make any promises.
I think there are two significant bits there:
* Fixing the parsetr
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Included is the latest patches against CVS HEAD.
I spent some time reading this patch. Here are a few comments in
no particular order:
RangeRecursive node lacks copyfuncs/equalfuncs support.
Query.recursive is missed in equalfuncs.c. But rather than f
On Mon, 2008-09-15 at 22:41 -0700, David Fetter wrote:
> On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
> > > > * Single Evaluation:
> > > >
> > > > with
> > > > foo(i) as (select random() as i)
> > > > select * from foo union all select * from foo;
> > > >i
> >
On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
> > > * Single Evaluation:
> > >
> > > with
> > > foo(i) as (select random() as i)
> > > select * from foo union all select * from foo;
> > >i
> > > ---
> > >0.233165248762816
> > > 0.621266
> > * Single Evaluation:
> >
> > with
> > foo(i) as (select random() as i)
> > select * from foo union all select * from foo;
> >i
> > ---
> >0.233165248762816
> > 0.62126633618027
> > (2 rows)
> >
> > The standard specifies that non-recursive WIT
> I meant that -- hypothetically if we did accept the feature as-is -- the
> number of evaluations would be documented to be undefined, not N. That
> would avoid the backwards-compatibility problem.
>
> This one point is probably not worth discussing now, because argument
> #1 and #2 stand on their
On Tue, 2008-09-09 at 09:47 -0400, Robert Haas wrote:
> > 3. "I think this is a "must fix" because of the point about volatile
> > functions --- changing it later will result in user-visible semantics
> > changes, so we have to get it right the first time."
> >
> > I don't entirely agree with #3. I
"Robert Haas" <[EMAIL PROTECTED]> writes:
>> I am blind, I didn't find any reason, why materialisation isn't useable.
> I believe it's because of these two (closely related) problems:
> # The basic
> # implementation clearly ought to be to dump the result of the subquery
> # into a tuplestore an
2008/9/9 Jeff Davis <[EMAIL PROTECTED]>:
> On Tue, 2008-09-09 at 18:51 +0200, Pavel Stehule wrote:
>> hmm. I solve similar problem in grouping sets :( etc
>>
I have special executor node - feeder, it hold one tuple and others
nodes read from this node. It's usable for hash aggregates.
Pavel
plan
On Tue, 2008-09-09 at 18:51 +0200, Pavel Stehule wrote:
> hmm. I solve similar problem in grouping sets :( etc
>
How did you solve it?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
2008/9/9 Robert Haas <[EMAIL PROTECTED]>:
>> My interpretation of 7.13: General Rules: 2.b is that it should be
>> single evaluation, even if RECURSIVE is present.
>>
>> The previous discussion was here:
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-07/msg012
>>> >> My interpretation of 7.13: General Rules: 2.b is that it should be
>>> >> single evaluation, even if RECURSIVE is present.
>>> >>
>>> >> The previous discussion was here:
>>> >>
>>> >> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01292.php
>
> I am blind, I didn't find any reason
2008/9/9 Tatsuo Ishii <[EMAIL PROTECTED]>:
>> Hello
>>
>> 2008/9/9 Tatsuo Ishii <[EMAIL PROTECTED]>:
>> >> On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
>> >> > Thanks for the review.
>> >> >
>> >> > > The standard specifies that non-recursive WITH should be evaluated
>> >> > > once.
>
> > * Aggregates allowed:
> >
> > with recursive foo(i) as
> > (values(1)
> > union all
> > select max(i)+1 from foo where i < 10)
> > select * from foo;
> >
> > Aggregates should be blocked according to the standard.
> > Also, causes an infinite loop. This should be fixed for
> Hello
>
> 2008/9/9 Tatsuo Ishii <[EMAIL PROTECTED]>:
> >> On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
> >> > Thanks for the review.
> >> >
> >> > > The standard specifies that non-recursive WITH should be evaluated
> >> > > once.
> >> >
> >> > What shall we do? I don't think there
> Hello
>
> 2008/9/9 Tatsuo Ishii <[EMAIL PROTECTED]>:
> >> On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
> >> > Thanks for the review.
> >> >
> >> > > The standard specifies that non-recursive WITH should be evaluated
> >> > > once.
> >> >
> >> > What shall we do? I don't think there
Hello
2008/9/9 Tatsuo Ishii <[EMAIL PROTECTED]>:
>> On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
>> > Thanks for the review.
>> >
>> > > The standard specifies that non-recursive WITH should be evaluated
>> > > once.
>> >
>> > What shall we do? I don't think there's a easy way to fix
> On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
> > Thanks for the review.
> >
> > > The standard specifies that non-recursive WITH should be evaluated
> > > once.
> >
> > What shall we do? I don't think there's a easy way to fix this. Maybe
> > we should not allow WITH clause withou
> 3. "I think this is a "must fix" because of the point about volatile
> functions --- changing it later will result in user-visible semantics
> changes, so we have to get it right the first time."
>
> I don't entirely agree with #3. It is user-visible, but only in the
> sense that someone is depen
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
> Thanks for the review.
>
> > The standard specifies that non-recursive WITH should be evaluated
> > once.
>
> What shall we do? I don't think there's a easy way to fix this. Maybe
> we should not allow WITH clause without RECURISVE?
My
>> * Single Evaluation:
>>
>> with
>> foo(i) as (select random() as i)
>> select * from foo union all select * from foo;
>>i
>> ---
>>0.233165248762816
>> 0.62126633618027
>> (2 rows)
>>
>> The standard specifies that non-recursive WITH should be ev
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
> These are my initial comments ab
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
> These are my initial comments ab
On Mon, 2008-09-08 at 22:53 +0100, Andrew Gierth wrote:
> Yes, you've misinterpreted. When the spec says that a query "shall
> not" do such-and-such, it means that a conforming client isn't allowed
> to do that, it does NOT mean that the server is required to produce an
> error when it sees it.
>
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> Aggregates should be blocked according to the standard.
Jeff> Also, causes an infinite loop. This should be fixed for 8.4.
>> Does the standard require anywhere that non-conforming statements
>> must be diagnosed? (seems impractical
On Mon, 2008-09-08 at 18:08 +0100, Andrew Gierth wrote:
> Jeff> * Mutual Recursion:
>
> This limitation isn't at all uncommon in other implementations; DB2
> docs for example say:
As with some other things in my list, this doesn't need to be supported
in 8.4. I just wanted to lay out my interpre
On Mon, 2008-09-08 at 21:13 +0100, Gregory Stark wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
>
> > * Mutual Recursion:
> >
> > with recursive
> > foo(i) as (values(1) union all select i+1 from bar where i < 10),
> > bar(i) as (values(1) union all select i+1 from foo where i < 10)
> >
Jeff Davis <[EMAIL PROTECTED]> writes:
> * Mutual Recursion:
>
> with recursive
> foo(i) as (values(1) union all select i+1 from bar where i < 10),
> bar(i) as (values(1) union all select i+1 from foo where i < 10)
> select * from foo;
> ERROR: mutual recursive call is not supporte
> "Jeff" == Jeff Davis <[EMAIL PROTECTED]> writes:
Jeff> * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
"If more than one common table expression is defined in the same
statement, cyclic references between the common table expre
These are my initial comments about the Common Table Expressions (CTE)
patch, also known as WITH [RECURSIVE]. These comments are based on the
patch here:
http://archives.postgresql.org/pgsql-patches/2008-08/msg00021.php
This is a semantically complex feature, and the standard is fairly
complex a
67 matches
Mail list logo
