Marko Tiikkaja escribió:
> Tom Lane wrote:
> >The only thing that I'd be comfortable with is
> >copying the snap and modifying the copy.
>
> I don't see an easy way to do that with the current code;
> CopySnapshot() is static and PushUpdatedSnapshot() seems to be a bit
> of a pain since it messes
Tom Lane wrote:
The only thing that I'd be comfortable with is
copying the snap and modifying the copy.
I don't see an easy way to do that with the current code; CopySnapshot()
is static and PushUpdatedSnapshot() seems to be a bit of a pain since it
messes up some of the existing code which u
Tom Lane wrote:
It would be
altogether cleaner though if the CommandCounterIncrement responsibility
were in the same place it is now, ie the caller of the executor. Which
could be possible if we restructure the rewriter/planner output as a
list of Queries instead of just one. I'm not currently
Marko Tiikkaja writes:
> Tom Lane wrote:
>> (BTW, I also think
>> it would work better if you had the CommandCounterIncrement at the bottom
>> of the loop, after the subquery execution not before it. But I'm not sure
>> it's safe for ExecutePlan to be modifying the snapshot it's handed anyway.)
Tom Lane wrote:
1. I thought we'd agreed at
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
that the patch should support WITH on DML statements, eg
with (some-query) insert into foo ...
This might not take much more than grammar additions, but it's
definitely lacking at
On Sat, Nov 28, 2009 at 11:59, Tom Lane wrote:
> 1. I thought we'd agreed at
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
> that the patch should support WITH on DML statements, eg
> with (some-query) insert into foo ...
> This might not take much more than grammar ad
Marko Tiikkaja writes:
> Attached is the latest version of the patch.
I looked through this patch and concluded that it still needs a fair
amount of work, so I'm bouncing it back for further work.
1. I thought we'd agreed at
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
that
I wrote:
> I think this is worth doing since it cleans up one of the grottier
> parts of executor initialization. The whole thing around
> ExecContextForcesOids was never pretty, and it's been the source of
> more than one bug if memory serves.
On further review there's a really serious stumbling
Marko Tiikkaja writes:
> Tom Lane wrote:
>> since OIDs in user tables have been deprecated for several versions
>> now, I'm thinking that maybe the case doesn't arise often enough to
>> justify keeping such a wart in the executor.
> Under the circumstances I'd lean towards this option.
I've been
Tom Lane wrote:
What this misses is EvalPlanQual, which can require
initialization of a new plan tree during execution.
Agh. You're right, I missed that.
When I realized this, my first thought was that we might as well drop
all the proposed changes that involve avoiding use of
es_result_rela
Marko Tiikkaja writes:
> Attached is the latest version of the patch.
I started to look at this patch and soon noted that a very substantial
fraction of the delta had to do with getting rid of dependencies on
estate->es_result_relation_info. It seemed to me that if we were going
to do that, we s
Argh hit the wrong reply button...
-- Forwarded message --
From: Alex Hunsaker
Date: Wed, Nov 25, 2009 at 10:20
Subject: Re: [HACKERS] Writeable CTE patch
To: Marko Tiikkaja
On Mon, Nov 23, 2009 at 14:33, Marko Tiikkaja
wrote:
> Hi,
>
> Sorry for the delay, I
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
wrote:
>> Also, after reading through the previous threads; it was not
>> immediately obvious that you dealt with
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
>> only allowing selects or values at the top level of with.
>
> T
Alex Hunsaker wrote:
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
Missed that one. Thanks.
-add some asserts to make sure places we use subplanstate now that it
can be null
(*note* AFAICT its a cant happen, b
On Sun, Nov 15, 2009 at 14:27, Marko Tiikkaja
wrote:
> I wrote:
>>
>> Attached is the latest version of this patch.
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
-add some asserts to make sure places we use subplan
I wrote:
Attached is the latest version of this patch.
Here's that same patch in context diff format. Sorry for the noise.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/queries.sgml
--- b/doc/src/sgml/queries.sgml
***
*** 1499,1505 SELECT 3, 'three';
SELECT select_list FRO
Hi,
Attached is the latest version of this patch.
I altered rewriting a bit (I've brought the problems with the previous
approach up a couple of times before) and this version should have the
expected output in all situations. This patch doesn't allow you to use
INSERT/UPDATE/DELETE as the t
17 matches
Mail list logo
