On Fri, Feb 12, 2010 at 9:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
>>> We could possibly put in some hack to disallow OLD/NEW references in
>>> the WITH queries, but that got past my threshold of ugliness, so
>>> I'm not going to commit it
Robert Haas writes:
> On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
>> We could possibly put in some hack to disallow OLD/NEW references in
>> the WITH queries, but that got past my threshold of ugliness, so
>> I'm not going to commit it without further discussion.
> On the face of it it's no
On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>>> Here's the patch. It's the same as the stuff in writeable CTE patches,
>>> but I added regression tests.
>
>> Whoops. The reference section in docs still had some traces of writeable
>> CTEs. Updated patch attached.
Marko Tiikkaja writes:
>> Here's the patch. It's the same as the stuff in writeable CTE patches,
>> but I added regression tests.
> Whoops. The reference section in docs still had some traces of writeable
> CTEs. Updated patch attached.
I spent some time playing with this but concluded that i
On Fri, Feb 12, 2010 at 12:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> This looks simple and useful. I haven't tested it, but if it's really
>> this easy, we should definitely do it.
>
> I should be out from under the window functions patch tomorrow,
> will look at this one then.
Cool, than
Robert Haas writes:
> This looks simple and useful. I haven't tested it, but if it's really
> this easy, we should definitely do it.
I should be out from under the window functions patch tomorrow,
will look at this one then.
regards, tom lane
--
Sent via pgsql-hackers
On Thu, Feb 11, 2010 at 12:35 PM, Marko Tiikkaja
wrote:
> On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
>> On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas
>> wrote:
>>> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
>>> wrote:
On 2010-02-11 03:44 +0200, I wrote:
> I'm going to have to d
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
> On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas
> wrote:
>> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
>> wrote:
>>> On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people and give up. :-(
>>>
>>> Btw. would i
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas
wrote:
> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
> wrote:
>> On 2010-02-11 03:44 +0200, I wrote:
>>> I'm going to have to disappoint a bunch of people and give up. :-(
>>
>> Btw. would it make sense to apply the WITH-on-top-of-DML part of th
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
wrote:
> On 2010-02-11 03:44 +0200, I wrote:
>> I'm going to have to disappoint a bunch of people and give up. :-(
>
> Btw. would it make sense to apply the WITH-on-top-of-DML part of this
> patch? At least to me, this seems useful because you can w
On 2010-02-11 03:44 +0200, I wrote:
> I'm going to have to disappoint a bunch of people and give up. :-(
Btw. would it make sense to apply the WITH-on-top-of-DML part of this
patch? At least to me, this seems useful because you can write a
RECURSIVE SELECT and then use UPDATE .. FROM or DELETE ..
On 2010-02-11 02:13 +0200, I wrote:
> On 2010-02-11 01:58 +0200, Robert Haas wrote:
>> I have to admit I've been starting to have a feeling over the last
>> couple of days that this patch isn't going to make it for 9.0... but
>> obviously I'm in no position to guarantee anything one way or the
>>
On 2010-02-11 01:58 +0200, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
> wrote:
>> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
>> Ok, what about the following:
>> - after planning the original query, standard_planner() goes through
>>the list of top-level CTEs an
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
wrote:
> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
>> On 2010-02-10 23:57 +0200, Tom Lane wrote:
>>> Robert Haas writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that me
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
> On 2010-02-10 23:57 +0200, Tom Lane wrote:
>> Robert Haas writes:
>>> If the executor has buried in it the assumption that the snapshot
>>> can't change after startup, then does that mean that we need to start
>>> up and shut down the executor for
On 2010-02-10 23:57 +0200, Tom Lane wrote:
> Robert Haas writes:
>> If the executor has buried in it the assumption that the snapshot
>> can't change after startup, then does that mean that we need to start
>> up and shut down the executor for each subquery?
>
> Yes, I think so. That's the way i
Robert Haas writes:
> If the executor has buried in it the assumption that the snapshot
> can't change after startup, then does that mean that we need to start
> up and shut down the executor for each subquery?
Yes, I think so. That's the way it's always worked in the past;
see for example Porta
On 2010-02-10 21:59 +0200, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
> wrote:
>> On 2010-02-10 03:20 +0200, Tom Lane wrote:
>>> Marko Tiikkaja writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
> You still haven't explained why it's a good idea to change the sn
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
wrote:
> On 2010-02-10 03:20 +0200, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at
On 2010-02-10 03:20 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2010-02-10 02:19 +0200, Tom Lane wrote:
>>> You still haven't explained why it's a good idea to change the snapshot
>>> after the executor has started. Right at the moment I'm prepared to
>>> reject the patch on that ground
Marko Tiikkaja writes:
> On 2010-02-10 02:19 +0200, Tom Lane wrote:
>> You still haven't explained why it's a good idea to change the snapshot
>> after the executor has started. Right at the moment I'm prepared to
>> reject the patch on that ground alone.
> The patch only touches the snapshot's
On 2010-02-10 02:19 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> Does this sound completely unacceptable?
>
> You still haven't explained why it's a good idea to change the snapshot
> after the executor has started. Right at the moment I'm prepared to
> reject the patch on that ground alon
Marko Tiikkaja writes:
> On 2010-02-08 21:30 +0200, I wrote:
>> This doesn't exactly work anymore since we modify the snapshot after
>> calling ExecInitScan(). I'm not really familiar with this part of the
>> code, so I'm asking: is there a simple enough way around this? Would
>> updating scan->
On 2010-02-08 21:30 +0200, I wrote:
> This doesn't exactly work anymore since we modify the snapshot after
> calling ExecInitScan(). I'm not really familiar with this part of the
> code, so I'm asking: is there a simple enough way around this? Would
> updating scan->rs_nblocks before scanning the
On 2010-02-09 01:09 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> I traced this down to heapam.c, which has this:
>> ...
>> This doesn't exactly work anymore since we modify the snapshot after
>> calling ExecInitScan().
>
> So don't do that. The executor is generally entitled to assume that
Marko Tiikkaja writes:
> I traced this down to heapam.c, which has this:
> ...
> This doesn't exactly work anymore since we modify the snapshot after
> calling ExecInitScan().
So don't do that. The executor is generally entitled to assume that
parameters given to ExecutorStart are correct. In p
Hi,
While playing around with another issue with the patch, I came across
the following:
=> create table foo(a int);
CREATE TABLE
=> with t as (insert into foo values(0)) select * from foo;
a
---
(0 rows)
I traced this down to heapam.c, which has this:
/*
* return null immediately if relation
27 matches
Mail list logo
