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. T
eally 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 first tuple be OK?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> - I'm not sure that canSetTag is th
thal. David Fetter has been doing a lot of
> presentations on the feature; surely he could turn them into some
> documentation? David?
The documentation has definitely improved from the last time Robert
looked at it, but I fear it still needs some more work. I'm willing to
do that work,
On 2010-02-05 07:14 UTC+2, Takahiro Itagaki wrote:
>
> Marko Tiikkaja wrote:
>
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> * In the regression tests, almost all of them don&
ibpq's documentation. Is there one somewhere?
While working on the docs, I noticed one problem with the patch itself:
it doesn't handle multi-statement DO INSTEAD rules correctly. I'm going
to submit a fix for that later.
Any suggestions, whatsoever, are welcome.
Regards
On 2010-02-03 18:41 UTC+2, Merlin Moncure wrote:
> On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
> wrote:
>> Right. The documentation in its current state is definitely lacking.
>> I've tried to focus all the time I have in making this patch technically
>> good.
e
> main statement begins execution
> - each CTE will see the results of CTEs already executed, and the main
> statement will see the results of all CTEs
> - but queries within each CTE still won't see their own updates (a
> reference to whatever section of the manual we talk abou
as (select * from t) values(true);
ERROR: recursive query "t" does not have the form non-recursive-term
UNION [ALL] recursive-term
but I didn't want to throw people off to think that they can use
INSERT/UPDATE/RETURNING in a RECURSIVE CTE, just to get complaints about
syntax error.
ET i = i + 1 WHERE i = 2;
> ERROR: syntax error at or near "UNION"
WITH RECURSIVE t AS (INSERT INTO foo SELECT * FROM t) VALUES(true);
would do that. You can do the same with UPDATE .. FROM and DELETE .. USING.
> * The patch includes regression tests, but no error cases in it.
t; b) when second parameter is stable, then store it and use it as constant.
>
> I prefer a)
Someone might have a perfectly good use case for using different
delimiters. I don't think it's a good idea to be artificially limiting
what you can and can't do.
Regards,
Marko Tiikk
new function RegisterSnapshotCopy instead?
Sounds reasonable.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of it and has a fix ready.
>
> So it sounds like we should expect an updated patch shortly?
Yes. I'm adding more comments and documentation, expect a patch within
a couple of days.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 2010-01-07 18:13 +0200, Marko Tiikkaja wrote:
I had a similar syntax in mind, but instead of using threads, just
execute the file in order using asynchronous connections.
I completely failed to make the point here which was to somehow mark
which statements will (or, should) block. So here
in order using asynchronous connections.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d what
we're reaching for here. What I think would be most useful would be to
interleave statements between transactions, not just randomly fire psql
sessions and hope for race conditions.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
the actual problem in the original post.
The problem only affects INSERT, UDPATE and DELETE where you are
actually counting affected rows (i.e. PQcmdTuples(), not PQntuples()) so
the this example would work as expected.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgs
figure out what was wrong.
Is this documented somewhere?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
having
this seems like a useful feature in some cases. Although the DISTINCT
ON syntax would have a bit more resemblance on the existing syntax, I'd
still like to see agg(distinct x order by x,y).
Just my $0.02.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-h
code which uses the active snapshot
stack. Any ideas?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ently sure how hard
that would be, though; it might not be a practical answer.
I'm trying to avoid doing this, at least for now.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
m
doing is wrong?
4. As previously noted, the changes to avoid using es_result_relation_info
are broken and need to be dropped from the patch.
Done. I kept the logic for result relations to allow nested ModifyTable
nodes, but I don't think it ever did the right thing with EvalPlanQual()
and nested nodes
#x27;t arise often enough to
justify keeping such a wart in the executor.
Under the circumstances I'd lean towards this option.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t doesn't sound like a bad idea..
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the same Oracle uses, and I
think it's nice for the general case, but I think the reversed operator
weirdness is a bit too much. Maybe we should use something like
PARTITION bar VALUES OPERATOR 0
when the user specifies the operator?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailin
op-level statement or not.
I'll send an updated patch in a couple of days.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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';
SEL
's
something to think about.
Regards,
Marko Tiikkaja
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index b2741bc..3aa7da5 100644
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -1499,7 +1499,7 @@ SELECT 3, 'three';
SELECT select_list FROM
Tom Lane wrote:
Marko Tiikkaja writes:
I wouldn't care for this at all, but with things the way they are right
now, the writeable CTE patch has to do quite a few of these:
[ shrug... ] How many is "quite a few"? In a quick search for existing
references to targetList in
Tom Lane wrote:
Marko Tiikkaja writes:
Tom Lane wrote:
This doesn't really seem like a good idea from here. You're changing
a decision that has something like twenty years' standing in the code,
for no real gain. AFAICS this is just going to move the special cases
from poi
oint B.
Right, but this way you only have to special-case in grouping_planner(),
and targetList always means the same thing.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
#x27;ll be glad to do it if people think this is useful.
Thoughts?
Regards,
Marko Tiikkaja
*** a/src/backend/executor/functions.c
--- b/src/backend/executor/functions.c
***
*** 1070,1078 check_sql_fn_retval(Oid func_id, Oid rettype, List
*queryTreeList,
n't read all
the output of a portal", but at least for cursors we'd have to first
execute ModifyTable nodes.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
but I don't think it matters because those
trigger calls would have a different snapshot, right? Or am I missing
something?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
T or an INSERT. Also, UPDATEs
and DELETEs inside CTEs can't have the same result relations. Whether
or not we want to break the expected(?) behaviour for statement-level
triggers, I have no opinion to way or another.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hack
ome
cases we could inline the CTE for this to actually be a quite
significant performance benefit, so I'm not too fancy about the approach
you're suggesting.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
ughly yet, but I don't see any obvious problems.
I'd appreciate any input.
Regards,
Marko Tiikkaja
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index b2741bc..111ed6a 100644
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -1499,7 +1499,7 @@ SELEC
ITH t AS (DELETE FROM foo RETURNING id)
UPDATE bar SET foo_id = NULL FROM t WHERE t.id = bar.foo_id;
Did I misunderstand something here?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
taking it out now seemed like moving backward.
Ok.
2. Move actual execution of (non-deferred) AFTER triggers inside
ModifyTuple. This might be a good idea in order to have the most
consistent results for a series of WITH queries, but I'm not sure.
This definitely seems like the best opti
hinking that this should be part of the writeable CTE patch.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm a bit tired
of that topic right now.
I'm sorry, it didn't occur to me that this is part of this patch, but I
made these changes in my writeable CTE repo, see
http://git.postgresql.org/gitweb?p=writeable_cte.git;a=commitdiff;h=41ad3d24af845c67a3866e0946129cf9809fe7e9
Regards,
Ma
Tom Lane wrote:
Does anyone have a problem with the ModifyTable suggestion,
or a better idea?
Lacking a better idea, +1 for ModifyTable from me.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
RNING clause if the CTE isn't
referenced, so you could write this as:
WITH t1 AS
(UPDATE foo SET bar=bar+1),
t2 AS
(UPDATE baz SET bar=bar+1)
VALUES(true);
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ain after CommitFest.
Agreed.
Does this have any impact on the pending DML-node patch?
Not really. This could be done without the patch, but we can use far
more of the existing CTE code with the patch.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
wrote:
Right. This is exactly what I'm trying to do, except I think we could
easily optimize this case and store only the first processed row inside
the CTE.
why? we don't should be thinking in optimizations in
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
wrote:
1) WITH t AS
(UPDATE foo SET bar = bar+1 RETURNING *)
SELECT * FROM t LIMIT 1;
What's problematic here is that only 1 row is read from the CTE, meaning
also that only one row is updated whic
the main execution tree and execute
it using the data we now have inside the CTEs. This way we can avoid
storing useless rows in memory without unexpected behaviour and caveats.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
/UPDATE/DELETE
works as expected here.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
INTO foo
WITH t AS ( DELETE FROM bar RETURNING * )
SELECT * FROM t;
which is probably the most useful thing you could do with this feature.
Am I misinterpreting what you said?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
t;project".
I'm going to go ahead and mark this Ready for Committer. Thanks for
your patience.
Thanks for reviewing!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ould be executed separately. I'm not saying that we don't
want to provide the means to do this, but writeable CTEs alone aren't
meant to handle this.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;t accomplish
anything, but supporting writeable CTEs will be a lot easier as seen in
the git repo David pointed you to.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
Can you at least take a stab at it? We can fix your grammar, but
guessing what's going on without documentation is hard.
With some help from David Fetter, I took another try at it. I hope
someone finds this helpful. I'm happy to answer any questions.
Rega
e
and submit an updated patch in a couple of days.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ues that
I'm aware of. There are a few spots that could be prettier, but I have
no good ideas for them.
I'll try to provide some more feedback on this after I look it over some more.
Thanks!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
I've looked at implementing writeable CTEs on top of my DML node patch
(repo here: git://git.postgresql.org/git/writeable_cte.git ) and
encountered a few conundrums. You can see what I've done in the
"actually_write" branch of that repo.
- Currently we only store the OIDs of the result rela
, and bar was
0, so I couldn't put bar != 0 into the WHERE clause. This time I got
around it by using RETURNING bar and checking that it was 1 on the
client side, but I can come up with other cases where you can't do that.
Comments?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hacke
On 7/31/2009, "Marko Tiikkaja" wrote:
> ..
I seem to be having problems with my email client. The patch should be
attached this time. Sorry for the noise.
Regards,
Marko Tiikkaja
patch3
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
but the idea was that if the DML node has a
RETURNING
clause, the node returns the projected tuple and ExecutePlan sends it to
the DestReceiver.
In cases where there is no RETURNING clause, the node would return a
dummy tuple.
Comments are welcome.
Regards,
Marko Tiikkaja
--
Sent vi
slot isn't
allocated in InitPlan(). Seems to be one of the many places where the
code isn't aware that there can be a non-top-level DML statement. Thanks
for testing.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
Hello.
Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE.
Should apply cleanly against CVS head.
The INSERT query isn't rewritten so rules and default values don't work.
Recursive CTEs don't work either.
Regards,
Marko Tiikkaja
*** a/src/backend/comm
601 - 661 of 661 matches
Mail list logo