On Tue, Aug 15, 2017 at 7:43 AM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Mon, Aug 14, 2017 at 6:23 PM, Marko Tiikkaja <ma...@joh.to> wrote:
> > Attached is a patch for $SUBJECT. It might still be a bit rough around
> the
> > edges and probably light on docs and t
Hi,
Attached is a patch for $SUBJECT. It might still be a bit rough around the
edges and probably light on docs and testing, but I thought I'd post it
anyway so I won't forget.
.m
insert_conflict_select_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
On Fri, Jul 1, 2016 at 2:12 AM, I wrote:
> Currently the tuple returned by INSTEAD OF triggers on DELETEs is only
> used to determine whether to pretend that the DELETE happened or not, which
> is often not helpful enough; for example, the actual tuple might have been
> concurrently UPDATEd by
On Thu, Apr 27, 2017 at 4:13 PM, Bruce Momjian wrote:
> On Thu, Apr 27, 2017 at 08:00:28AM +0530, Amit Kapila wrote:
> > > Oh, so non-correlated subqueries can be run in parallel. Yes, that is
> > > something we should have in the release notes. How is this?
> > >
> > >
On Thu, Oct 12, 2017 at 12:03 PM, tushar
wrote:
> postgres=# SELECT * FROM ( SELECT n from tv where n= (select * from
> (select n from tv limit 1) c)) as c ;
> n
> --
> 3713
> (1 row)
>
> This time , query is started showing wrong result. Is this an
Hi Markus,
On Sun, Aug 20, 2017 at 9:56 PM, Markus Sintonen
wrote:
> I also encountered this when I built it with different configuration. I
> attached updated patch with the correct number of arguments to
> 'similar_escape'. I also added preliminary documentation to
On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Marko Tiikkaja <ma...@joh.to> writes:
> > I wonder if the nested loop shouldn't have some kind of a cap on its own
> > estimate if it's wildly off of what you'd get by multiplying the child
>
On Fri, Sep 29, 2017 at 9:31 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> I wonder why syntax error is produced in this case:
>
> postgres=# create index metaindex on foo using gin(to_tsvector('english',
> x)||to_tsvector('english',y));
> ERROR: syntax error at or near "||"
>
On Mon, Sep 4, 2017 at 4:09 AM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Tue, Aug 15, 2017 at 12:17 AM, Marko Tiikkaja <ma...@joh.to> wrote:
> > On Tue, Aug 15, 2017 at 7:43 AM, Peter Geoghegan <p...@bowt.ie> wrote:
> >>
> >> On Mon, Aug 14, 2017 at
On Mon, Sep 4, 2017 at 7:46 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Mon, Sep 4, 2017 at 10:05 AM, Marko Tiikkaja <ma...@joh.to> wrote:
> But I'm generally against
> > interfaces which put arbitrary restrictions on what power users can do on
> > the basis that
Hi,
I just came across this very peculiar behavior:
=# create table foo(id int primary key);
CREATE TABLE
=# insert into foo select generate_series(1, 100);
INSERT 0 100
=# set enable_hashjoin to false; set enable_mergejoin to false;
SET
SET
=# explain select * from foo where id in
On Wed, Oct 25, 2017 at 5:32 PM, Michael Paquier
wrote:
> On Mon, Oct 23, 2017 at 6:50 AM, Michael Paquier
> wrote:
> > Okay, attached is what I think a fully implemented patch should look
> > like. On top of what Andrew has done, I added
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';
synopsis
SELECT
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
, 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 mailing list (pgsql-hackers
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
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
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. I'll have think about that.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
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.org/mailpref
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
and 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-hackers
not 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
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 (pgsql-hackers
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.org)
To make changes to your
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
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
.
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.org)
To make changes to your subscription:
http
on modifying it. A comment
explaining this might be in order.
If the copy is necessary (e.g. because the snapshot must not be modified
externally, and there's actual risk that it is), then maybe it would be
better to create a new function RegisterSnapshotCopy instead?
Sounds reasonable.
Regards,
Marko
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 Tiikkaja
--
Sent via pgsql-hackers mailing list
the same with UPDATE .. FROM and DELETE .. USING.
* The patch includes regression tests, but no error cases in it.
More test cases are needed for stupid queries.
Ok, I'll add these and send an updated patch in a few hours.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
(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.
Regards,
Marko Tiikkaja
--
Sent via
)
- possible pitfalls of CTEs not being pipelined
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.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2010-02-03 18:41 UTC+2, Merlin Moncure wrote:
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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.
Do you
. 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,
Marko Tiikkaja
*** a/doc/src/sgml
On 2010-02-05 07:14 UTC+2, Takahiro Itagaki wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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't have ORDER
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, but I need something concrete.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
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 the right name for the additional
argument
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 subscription:
http://www.postgresql.org/mailpref/pgsql
On 2010-02-09 01:09 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 2010-02-08 18:42 +0200, Robert Haas wrote:
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
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
whenever the scan nodes need to reinit.
Does this sound completely unacceptable?
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
On 2010-02-10 02:19 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 2010-02-10 21:59 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't
.
I'm looking at this, but I can't think of any good way of associating
the tuplestores from PortalRunMulti() with the correct CTEs. Any ideas?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
On 2010-02-10 23:57 +0200, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On 2010-02-11 01:58 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
that there
would've been a shot, even if I finished the patch on time.
Thanks everyone for helping out and reviewing this, especially Robert
and Tom.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.. USING on that CTE.
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
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people
: (b = 2)
Total runtime: 0.075 ms
(3 rows)
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
,
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 the syntax
optional is just breaking that portability. We already have a
non-portable, non-standard syntax.
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
.
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
On 2010-03-29 11:19 +0200, Pavel Stehule wrote:
postgres=# explain select a from a left join b on true;
This is effectively a cross join and it would give wrong answers. Try
SELECT a FROM a LEFT JOIN b ON a.a = b.b;
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql
better, but I can't
think of anything.
Thoughts?
Regards,
Marko Tiikkaja
*** a/src/backend/parser/analyze.c
--- b/src/backend/parser/analyze.c
***
*** 730,742 transformInsertRow(ParseState *pstate, List *exprlist
;
DELETE 1
TXB = select a from foo for share; -- waits
What am I missing?
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
Zeilen)
T2 DELETE FROM a WHERE i = 1; -- Nope, so delete a with i = 1 (this
blocks, because T1 is still holding the lock).
Obviously you wouldn't delete anything with a SHARE lock.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
suggestion in a more general way,
suggesting the use of row-level locks. T2 should be holding an
exclusive row-level lock (SELECT ... FOR UPDATE) when checking for
references.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
the rows in a serializable
transaction so this doesn't solve the problem.
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
:
CREATE UNIQUE INDEX a_single_row ON a ((1));
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
, 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-hackers mailing list
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
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
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
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.
Regards,
Marko
, 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
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
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
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 your
.
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 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 your subscription:
http://www.postgresql.org
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
.
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)
To make changes
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 your subscription:
http
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
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,
Marko Tiikkaja
--
Sent via
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
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 option to me.
Regards,
Marko Tiikkaja
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
.
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 @@ SELECT 3, 'three';
synopsis
SELECT replaceableselect_list
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 subscription:
http://www.postgresql.org
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-hackers
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/mailpref/pgsql
, 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
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,
(parse
, 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
Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
,
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';
synopsis
SELECT replaceableselect_list/replaceable FROM
that.
Having said that, I also think that supporting in exclusion
constraints would be useful. I can't come up with a real-world use case
right now though.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to do it.
As far as I recall, at least 99% of the user requests for this type
of behavior, maybe 100%, would be satisfied by recognizing the
group-by-primary-key case. So I think we should do that and be happy.
+1
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
any obvious flaws in this?
Any feedback is welcome. I'd also be happy to get some help on this
project.
Regards,
Marko Tiikkaja
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 1092,1098 DoCopy(const CopyStmt *stmt, const char *queryString
On 7/12/10 9:07 PM +0300, I wrote:
Consider:
WITH t AS (SELECT 1),
t2 AS (SELECT * FROM t2)
VALUES (true);
That should of course have been SELECT * FROM t, not t2.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
queries into a list of Queries and store that
list into the CommonTableExprs. The planner would then use this
information and also expand the rewrite products.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
it.
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
be
to unconditionally force the tuplestores to disk, but that sounds painful.
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
? And if I didn't, why do we do this
differently?
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
1 - 100 of 655 matches
Mail list logo