Hitoshi Harada writes:
> 2010/10/5 Marko Tiikkaja :
>> This patch conflicted with Tom's WITH .. INSERT change. I tweaked the
>> patch just a bit and it now passes all regression tests so I can review
>> it. New version attached for documentation purposes.
> Thank you, I didn't notice that commi
On 2010-10-05 3:37 PM +0300, Hitoshi Harada wrote:
2010/10/5 Marko Tiikkaja:
This patch conflicted with Tom's WITH .. INSERT change. I tweaked the
patch just a bit and it now passes all regression tests so I can review
it. New version attached for documentation purposes.
Thank you, I didn't
2010/10/5 Marko Tiikkaja :
> (Oops, this didn't go to -HACKERS)
>
> On 2010-10-04 2:46 PM +0300, Erik Rijkers wrote:
>>
>> (HEAD from git://git.postgresql.org/git/postgresql.git)
>>
>> The patch applies only with error.
>> If that error is ignored, the regression 'with' test failes.
>> If that is a
(Oops, this didn't go to -HACKERS)
On 2010-10-04 2:46 PM +0300, Erik Rijkers wrote:
(HEAD from git://git.postgresql.org/git/postgresql.git)
The patch applies only with error.
If that error is ignored, the regression 'with' test failes.
If that is also ignored, it runs.
This patch conflicted w
2010/10/1 Hitoshi Harada :
> 2010/9/30 Marko Tiikkaja :
>> On 2010-09-23 9:12 AM +0300, Hitoshi Harada wrote:
>>>
>>> Since the transformation of
>>> WITH clause to cheat postgres is in the parser stage currently, I
>>> wonder if this should be done in the rewriter or the planner stage.
>>
>> It's
On 2010-09-23 9:12 AM +0300, Hitoshi Harada wrote:
Thanks for the report. Next time, please point the clear problem in
English aside the sample.
I apologize. The problem was exactly the one pointed out in the email I
referred to, so I assumed that further explanation was not necessary.
I wi
2010/9/23 Marko Tiikkaja :
> On 2010-09-17 4:48 AM, Hitoshi Harada wrote:
>>
>> 2010/9/15 Hitoshi Harada:
>>>
>>> Well, I didn't know it is allowed. That would look like the way to go.
>>
>> I made changes to the previous version, so that it avoids to resolve
>> CTE name duplication.
>
> This patch
On 2010-09-17 4:48 AM, Hitoshi Harada wrote:
2010/9/15 Hitoshi Harada:
Well, I didn't know it is allowed. That would look like the way to go.
I made changes to the previous version, so that it avoids to resolve
CTE name duplication.
This patch still doesn't address the issue Tom raised here:
2010/9/15 Hitoshi Harada :
> 2010/9/15 Tom Lane :
>>
>> Well, I would think that the no-duplication rule applies to each WITH
>> list separately, not both together. If you do something like
>>
>> with t1 as (select * from foo)
>> select * from
>> (with t2 as (select * from foo)
>> select
2010/9/15 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/15 Tom Lane :
>>> Why is it so difficult to do this correctly?
>
>> Because INSERT INTO ... (SELECT|VALUES) is already a collection of
>> kludge (as comments say). It was possible to parse the two WITHs
>> separately, but it results in ambigu
Hitoshi Harada writes:
> 2010/9/15 Tom Lane :
>> Why is it so difficult to do this correctly?
> Because INSERT INTO ... (SELECT|VALUES) is already a collection of
> kludge (as comments say). It was possible to parse the two WITHs
> separately, but it results in ambiguous naming issue;
> parseWith
2010/9/15 Tom Lane :
> Marko Tiikkaja writes:
>> On 2010-09-14 10:51 PM, Tom Lane wrote:
>>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>>> its scope of visibility, so that confusing the two cases can result in
>>> flat-out incorrect parser behavior.
>
>> The worst I
2010/9/15 Marko Tiikkaja :
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>> its scope of visibility, so that confusing the two cases can result in
>> flat-out incorrect parser behavior.
>
> The worst I can think of is:
>
> CREA
Marko Tiikkaja writes:
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>> its scope of visibility, so that confusing the two cases can result in
>> flat-out incorrect parser behavior.
> The worst I can think of is:
> CREATE TA
On Tue, Sep 14, 2010 at 4:28 PM, Marko Tiikkaja
wrote:
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>>
>> Hitoshi Harada writes:
>>>
>>> 2010/9/15 Marko Tiikkaja:
In the email you referred to, Tom was concerned about the case where
these
WITH lists have different RECURSIVE declar
On 2010-09-14 10:51 PM, Tom Lane wrote:
Hitoshi Harada writes:
2010/9/15 Marko Tiikkaja:
In the email you referred to, Tom was concerned about the case where these
WITH lists have different RECURSIVE declarations. This patch makes both
RECURSIVE if either of them is. I can think of cases whe
Hitoshi Harada writes:
> 2010/9/15 Marko Tiikkaja :
>> In the email you referred to, Tom was concerned about the case where these
>> WITH lists have different RECURSIVE declarations. This patch makes both
>> RECURSIVE if either of them is. I can think of cases where that might lead
>> to surpris
2010/9/15 Marko Tiikkaja :
> On 2010-09-13 4:15 PM +0300, Hitoshi Harada wrote:
>>
>> 1. WITH clause atop INSERT
>> Although the previous discussion got the consensus that we forbid WITH
>> atop INSERT, it seems to me that it can be allowed. I managed to do it
>> by treating the top WITH clause (of
On 2010-09-13 4:15 PM +0300, Hitoshi Harada wrote:
1. WITH clause atop INSERT
Although the previous discussion got the consensus that we forbid WITH
atop INSERT, it seems to me that it can be allowed. I managed to do it
by treating the top WITH clause (of INSERT) as if the one of SELECT
(or VALUE
2010/9/14 Merlin Moncure :
> On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas wrote:
>> On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
>>> The patch attached is based on the one rejected at the last CF for 9.0
>>> last year.
>>>
>>> http://archives.postgresql.org/message-id/16303.1266023...@s
On Mon, Sep 13, 2010 at 2:43 PM, Merlin Moncure wrote:
> Just to be clear, the attached patch is missing the part of the wCTE
> that allows queries of the form:
> WITH foo AS (DELETE * FROM bar RETURNING *)
Understood.
> IOW, your CTE query has to be a select. This is still highly useful
> how
On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas wrote:
> On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
>> The patch attached is based on the one rejected at the last CF for 9.0
>> last year.
>>
>> http://archives.postgresql.org/message-id/16303.1266023...@sss.pgh.pa.us
>>
>> This patch impl
On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
> The patch attached is based on the one rejected at the last CF for 9.0
> last year.
>
> http://archives.postgresql.org/message-id/16303.1266023...@sss.pgh.pa.us
>
> This patch implements the feature that allows top-level DMLs under CTE
> WIT
The patch attached is based on the one rejected at the last CF for 9.0
last year.
http://archives.postgresql.org/message-id/16303.1266023...@sss.pgh.pa.us
This patch implements the feature that allows top-level DMLs under CTE
WITH clause. For example:
WITH t AS (SELECT * FROM x)
UPDATE y SET val
24 matches
Mail list logo
