Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 1:36 AM, Tom Lane wrote:
Why is it necessary to hack the portal logic at all? The patch seems to
work for me without that. (I've fixed quite a few bugs though, so maybe
what this is really doing is masking a problem
On 2011-02-25 6:12 PM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
Without hacking it broke when PQdescribePrepared was called on a
prepared query like:
WITH t AS (DELETE FROM foo)
SELECT 1;
Not sure if that's an actual problem, but it seemed like something worht
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 6:12 PM, Tom Lane wrote:
The current implementation with everything in one plantree
really ought to look just like a SELECT so far as the portal code
is concerned.
The problem was that the old code was using
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I fixed an issue with the portal logic, and now we use
PORTAL_ONE_RETURNING for wCTE queries, even if the main query is not a
DML or does not have RETURNING. This also means that we materialize the
results of the main query sometimes
On 2011-02-25 1:36 AM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
I fixed an issue with the portal logic, and now we use
PORTAL_ONE_RETURNING for wCTE queries, even if the main query is not a
DML or does not have RETURNING. This also means that we materialize the
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the edges
and
needs some more comments, but I'm posting it here anyway.
Is this the patch
On tis, 2010-12-21 at 13:20 -0800, David Fetter wrote:
On Tue, Dec 21, 2010 at 11:14:31PM +0200, Peter Eisentraut wrote:
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
On 2010-12-22 8:24 PM, Peter Eisentraut wrote:
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the edges
and
needs some more comments, but I'm
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-12-22 8:24 PM, Peter Eisentraut wrote:
Is this the patch of record? There are no changes to the documentation
included.
I've kept the documentation as a separate patch, but I haven't touched
it in a very long time. I will work
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
On Tue, Dec 21, 2010 at 11:14:31PM +0200, Peter Eisentraut wrote:
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch
On Wed, Dec 08, 2010 at 01:23:59PM +0200, Marko Tiikkaja wrote:
On 2010-12-08 10:19 AM +0200, David Fetter wrote:
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
So this patch was marked Ready for Committer, but a) no committer
has picked it up yet and b) Marko has made changes
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
Marko Tiikkaja wrote:
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the
edges and needs some more comments, but I'm posting it here
anyway.
This patch passes all
On 2010-12-08 10:19 AM +0200, David Fetter wrote:
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
So this patch was marked Ready for Committer, but a) no committer
has picked it up yet and b) Marko has made changes here that nobody
else has tested out yet that I've seen on the last.
Marko Tiikkaja wrote:
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the edges
and needs some more comments, but I'm posting it here anyway.
This patch passes all regression tests, but feel free to try to break
it, there are
2010/11/14 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
On 2010-11-14 5:28 PM +0200, Hitoshi Harada wrote:
2010/11/14 Marko Tiikkajamarko.tiikk...@cs.helsinki.fi:
.. and a wild patch appears.
Could you update wiki on this feature if you think we've reached the consensus?
You're probably referring to
On 2010-11-14 8:01 PM +0200, I wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo.
Since the example wasn't entirely clear on this one: in my opinion the
DML should also only be executed once. So:
WITH t AS (INSERT INTO foo VALUES (0) RETURNING *)
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going to have trouble predicting
how a query is going to behave.
I think it's clear that's the
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going to have trouble predicting
how a query is going to
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any
On Sun, Nov 14, 2010 at 08:07:22PM +0200, Marko Tiikkaja wrote:
On 2010-11-14 8:01 PM +0200, I wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo.
Since the example wasn't entirely clear on this one: in my opinion
the DML should also only be executed
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga yebhavi...@gmail.com wrote:
What if CTE's ever get input parameters?
Then they'd be functions, which we already have.
If you mean something like
prepare foo(int) as
with x as
On 2010-11-14 21:06, Marko Tiikkaja wrote:
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all
rows
On tor, 2010-11-11 at 19:35 +0200, Marko Tiikkaja wrote:
I apologize, I had misunderstood what you are suggesting. But now
that I do, it seems to be an even worse idea to go your way. Based on
my research, I'm almost certain that the SQL standard says that the
execution order is
On Sun, Nov 14, 2010 at 11:02:08PM +0100, Yeb Havinga wrote:
On 2010-11-14 21:06, Marko Tiikkaja wrote:
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my
On 2010-11-12 16:51, David Fetter wrote:
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeah, that's another interesting question: should we somehow force
unreferenced CTEs to be evaluated anyhow?
Yes.
After a night's sleep I'm still thinking no. Arguments:
1) the name Common
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
On 2010-11-12 16:51, David Fetter wrote:
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeah, that's another interesting question: should we somehow force
unreferenced CTEs to be evaluated anyhow?
Yes.
After a night's
On 2010-11-13 14:41, David Fetter wrote:
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
1) the name Common Table Expression suggests that t must be
regarded as an expression, hence syntactically / proof theoretic and
not as a table, set of rows / model theoretic. I.e. it is not a
On 13 Nov 2010, at 15:41, David Fetter da...@fetter.org wrote:
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
On 2010-11-12 16:51, David Fetter wrote:
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeah, that's another interesting question: should we somehow force
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 13 Nov 2010, at 15:41, David Fetter da...@fetter.org wrote:
Similarly, if a normal CTE called a data-changing function but was
nevertheless not referred to, it would still run.
Actually, it wouldn't.
Indeed, and that was considered a
On 2010-11-13 5:08 PM +0200, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
On 13 Nov 2010, at 15:41, David Fetterda...@fetter.org wrote:
Similarly, if a normal CTE called a data-changing function but was
nevertheless not referred to, it would still run.
Actually, it
On Sat, 13 Nov 2010 17:23 +0200, Marko Tiikkaja wrote:
So these queries would behave differently?
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 WHERE false;
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 FROM t LIMIT 0;
I'm still trying to wrap my head around this
new mechanism.
On 2010-11-13 5:36 PM +0200, Clark C. Evans wrote:
On Sat, 13 Nov 2010 17:23 +0200, Marko Tiikkaja wrote:
So these queries would behave differently?
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 WHERE false;
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 FROM t LIMIT 0;
I'm still
On Sat, Nov 13, 2010 at 05:23:34PM +0200, Marko Tiikkaja wrote:
On 2010-11-13 5:08 PM +0200, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
On 13 Nov 2010, at 15:41, David Fetterda...@fetter.org wrote:
Similarly, if a normal CTE called a data-changing function but
was
On Sat, Nov 13, 2010 at 03:23:42PM +0100, Yeb Havinga wrote:
On 2010-11-13 14:41, David Fetter wrote:
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
1) the name Common Table Expression suggests that t must be
regarded as an expression, hence syntactically / proof theoretic and
Alvaro Herrera alvhe...@commandprompt.com writes:
It's not that straighforward though, in that the producer could stop a
bit ahead of what the consumer reads, due to there being a buffer in the
middle. Witness this simple example
Yeah, another example where the analogy fails for us.
--
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t AS (DELETE FROM foo)
SELECT * FROM foo;
And the big question is: what state of foo should the SELECT
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t AS (DELETE FROM foo)
SELECT * FROM foo;
And the big question
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t
On Fri, Nov 12, 2010 at 10:50:52AM -0500, Robert Haas wrote:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications
2010/11/13 Robert Haas robertmh...@gmail.com:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The
Hi all,
It appears that we have a consensus on the behaviour.
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sat, Nov 13, 2010 at 01:50:46AM +0900, Hitoshi Harada wrote:
2010/11/13 Robert Haas robertmh...@gmail.com:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to conclusion even if the outer query didn't
read it all
The counter-example that
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to conclusion even if the outer query didn't
Tom Lane t...@sss.pgh.pa.us writes:
I can see that there's a fair argument for that position in cases like
the above, but the trouble is that there are also cases where it's very
hard for the user to predict how many rows will be read. As examples,
mergejoins may stop short of reading all of
Excerpts from Dimitri Fontaine's message of vie nov 12 17:13:59 -0300 2010:
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
Hi all,
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how exactly
wCTEs should behave. The question seems to be whether or not a
statement should
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how exactly
wCTEs should behave. The question seems to
On 11 November 2010 16:50, Marko Tiikkaja marko.tiikk...@cs.helsinki.fiwrote:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how
On Nov 11, 2010, at 9:13 AM, Tom Lane wrote:
If we establish a precedent that WITHs can be thought of as executing
before the main command, we will eventually have to de-optimize existing
WITH behavior. Or else make up reasons why the inconsistency is okay in
some cases and not others, but
David E. Wheeler da...@kineticode.com writes:
I can see that, but if one can't see the result of the write, or can't
determine whether or not it will be visible in advance, what's the point of
writeable CTEs?
The writeable CTE returns a RETURNING set, which you can and should use
in the
Thom Brown t...@linux.com writes:
WITH t AS (UPDATE foo SET col = true)
SELECT * FROM foo WHERE col = false;
... Wouldn't this be more practical to have foo's UPDATEs applied prior to
SELECT? Otherwise what would the usecase be?
If that's what you want, you might as well just issue two
On 11 Nov 2010, at 19:13, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an indeterminate order, just
exactly the same way that different data modifications made in a single
On Nov 11, 2010, at 9:29 AM, Tom Lane wrote:
I can see that, but if one can't see the result of the write, or can't
determine whether or not it will be visible in advance, what's the point of
writeable CTEs?
The writeable CTE returns a RETURNING set, which you can and should use
in the
David E. Wheeler da...@kineticode.com writes:
On Nov 11, 2010, at 9:29 AM, Tom Lane wrote:
The writeable CTE returns a RETURNING set, which you can and should use
in the outer query. The thing that is being argued about here is what
you see if you look directly at the target table rather than
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an indeterminate order, just
exactly the same
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
Thom Brown t...@linux.com writes:
WITH t AS (UPDATE foo SET col = true)
SELECT * FROM foo WHERE col = false;
... Wouldn't this be more practical to have foo's UPDATEs applied
prior to SELECT? Otherwise what would the usecase be?
David Fetter da...@fetter.org writes:
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in parallel, or at least in an
On Thu, Nov 11, 2010 at 1:53 PM, David Fetter da...@fetter.org wrote:
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
then the conclusion is foregone. To my mind, they should be thought of
as running in
David Fetter da...@fetter.org writes:
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
If that's what you want, you might as well just issue two separate
statements. There is no use-case for this at all unless the WITH
produces some RETURNING data that the SELECT makes use of.
Hi all,
The discussion around wCTE during the last week or so has brought to my
attention that we don't actually have a consensus on how exactly wCTEs
should behave. The question seems to be whether or not a statement
should see the modifications of statements ran before it. While I think
67 matches
Mail list logo
