Marko Tiikkaja 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 PORTAL_MULTI_QUERY whenever
> a wCTE w
On 2011-02-25 6:12 PM, Tom Lane wrote:
Marko Tiikkaja 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
fixing.
I can't replicate su
Marko Tiikkaja 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 elsewhere.)
> Without hacking i
On 2011-02-25 1:36 AM, Tom Lane wrote:
Marko Tiikkaja 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 sometime
Marko Tiikkaja 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 unnecessarily, but that doesn
Marko Tiikkaja 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 the documentation if
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 p
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 wit
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
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
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 witho
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 c
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
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
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 pr
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
> >>> wrote:
> In my opinion, all of th
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 det
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
wrote:
In my opinion, all of these should have the same effect: DELETE all
rows
from "foo". Any other option me
Robert Haas writes:
> On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga 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 (delete from tab where id = $1 returning *)
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 ex
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga wrote:
> On 2010-11-14 19:35, Robert Haas wrote:
>>
>> On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
>> 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 ha
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
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
h
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
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
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
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 only sensible behavior.
-
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 *)
SEL
On 2010-11-14 5:28 PM +0200, Hitoshi Harada wrote:
2010/11/14 Marko Tiikkaja:
.. 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
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00660.php
which was
2010/11/14 Marko Tiikkaja :
> 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
> CommandCounterIncrement()
Alvaro Herrera 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.
--
Dimitri Fontaine
http://2ndQu
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 theore
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 Tiikkaja writes:
> >>On 13 Nov 2010, at 15:41, David Fetter wrote:
> >>>Similarly, if a normal CTE called a data-changing function but
> >>>was nevertheless not referred to, it
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 tryi
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 mechani
On 2010-11-13 5:08 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 13 Nov 2010, at 15:41, David Fetter 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
Marko Tiikkaja writes:
> On 13 Nov 2010, at 15:41, David Fetter 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 feature when we did it. I think
that havi
On 13 Nov 2010, at 15:41, David Fetter 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
unreferenced CTEs
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 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.
> Af
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 Tabl
Excerpts from Dimitri Fontaine's message of vie nov 12 17:13:59 -0300 2010:
> Tom Lane 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
Tom Lane 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 one input depen
Dimitri Fontaine writes:
> Tom Lane 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-e
Tom Lane 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 jumps to mind
On Sat, Nov 13, 2010 at 01:50:46AM +0900, Hitoshi Harada wrote:
> 2010/11/13 Robert Haas :
> > On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane wrote:
> >> Yeb Havinga writes:
> >>> On 2010-11-11 17:50, Marko Tiikkaja wrote:
> Just to be clear, the main point is whether they see the data
> mo
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 subscri
2010/11/13 Robert Haas :
> On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane wrote:
>> Yeb Havinga 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:
On Fri, Nov 12, 2010 at 10:50:52AM -0500, Robert Haas wrote:
> On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane wrote:
> > Yeb Havinga 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 ca
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
> Yeb Havinga 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 (DEL
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane wrote:
> Yeb Havinga 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)
Yeb Havinga 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 is: wh
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
state
David Fetter 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.
> There are lot
On Thu, Nov 11, 2010 at 1:53 PM, David Fetter 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 wrote:
>> > then the conclusion is foregone. To my mind, they should be thought of
>> > as running in parallel, or at least in an i
David Fetter 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 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
On Thu, Nov 11, 2010 at 12:34:55PM -0500, Tom Lane wrote:
> Thom Brown 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?
>
>
On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
> On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane 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 diff
"David E. Wheeler" 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 making
>>
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
>
On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane 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
> INSERT/UPDATE/DELETE command
On 11 Nov 2010, at 19:13, Tom Lane wrote:
Marko Tiikkaja 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
Thom Brown 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 separate
statem
"David E. Wheeler" 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 outer query. The th
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, bu
Marko Tiikkaja 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 exactly
>>> wCTEs sh
On 11 November 2010 16:50, Marko Tiikkaja wrote:
> 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 consen
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 be
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 sho
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
m
67 matches
Mail list logo
