On Sun, Apr 26, 2015 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/25/2015 08:01 PM, Michael Paquier wrote:
On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter
On 2015-04-25 20:47:04 -0400, Tom Lane wrote:
Since default_with_oids is really only meant as a backwards-compatibility
hack, I don't personally have a problem with restricting it to act only on
plain tables.
FWIW, I think we're getting pretty close to the point, or are there
even, where we
Hi
I reduced this patch, little bit cleaned - now it is based on plpgsql GUC
display_context_min_messages - like client_min_messages, log_min_messages.
Documentation added.
Regards
Pavel
2015-04-25 22:23 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
2015-04-24 19:16 GMT+02:00 Joel
On 04/25/2015 12:01 PM, Andres Freund wrote:
INSERT ... ON CONFLICT (cola, colb [WHERE predicate_for_partial]) UPDATE|IGNORE
My problem with the WHERE being inside the parens in the above is that
it's
a) different from CREATE INDEX
b) unclear whether the WHERE belongs to colb or the whole index
On 25/04/15 06:39, Jim Nasby wrote:
On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote:
On 24/04/15 05:24, Tom Lane wrote:
...
TBH, I've got very little enthusiasm for fixing this given the number
of reports of trouble from the field, which so far as I recall is zero.
Álvaro's case came up
Andres Freund and...@anarazel.de writes:
On 2015-04-26 19:13:42 +0400, Dmitriy Olshevskiy wrote:
- *therefor it is up to the calling routine to
+ *therefore it is up to the calling routine to
I think both are actually legal? Yes therefore is more common, but
still.
Hm. My
On 04/26/2015 03:13 AM, Michael Paquier wrote:
Oops, attached is a patch that should make currawong happier..
OK, pushed.
Argh. This is not enough:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawongdt=2015-04-26%2006%3A00%3A01
The build is done in Debug mode, but it is failing
Hello!
Please see this patch with several typos and
mistakes in comments.
There are also typos in sgml files (duplicate to):
1. doc/src/sgml/logicaldecoding.sgml, ln 619
Logical decoding can be used to to build
2. doc/src/sgml/ref/pg_dumpall.sgml, ln 457
Specifies the name of the database
Hi,
Man, whoever invented these an vs. a rules... But then this patch made
me lookup the rules ;)
On 2015-04-26 19:13:42 +0400, Dmitriy Olshevskiy wrote:
diff --git a/src/backend/optimizer/geqo/geqo_erx.c
b/src/backend/optimizer/geqo/geqo_erx.c
index 69ac077..1a43ab7 100644
---
Andres Freund and...@anarazel.de writes:
FWIW, I think we're getting pretty close to the point, or are there
even, where we can remove default_with_oids. So not adding complications
because of it sounds good to me.
Well, pg_dump uses it --- so the argument about not breaking old dump
scripts
On 26/04/15 12:08, Andres Freund wrote:
On April 26, 2015 11:22:01 AM GMT+02:00, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 04/25/2015 12:01 PM, Andres Freund wrote:
That's why I wanted the WHERE outside the (), which requires either
adding DO between the index inference clause, and the
v3, just a rebase.
Thanks for working on this. I see it's already registered in the
2015-06 CF, and will have a look at when we get there.
v4, rebase (after pgbench moved to src) and use of the recently added
syntax_error function.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 04/25/2015 12:01 PM, Andres Freund wrote:
INSERT ... ON CONFLICT (cola, colb [WHERE predicate_for_partial])
UPDATE|IGNORE
My problem with the WHERE being inside the parens in the above is that
it's
a) different from CREATE INDEX
b) unclear
On April 26, 2015 11:22:01 AM GMT+02:00, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 04/25/2015 12:01 PM, Andres Freund wrote:
INSERT ... ON CONFLICT (cola, colb [WHERE predicate_for_partial])
UPDATE|IGNORE
My problem with the WHERE being inside the parens in the above is
that
it's
a)
Here is v6, just a rebase.
Committed with minor stylistic fixes.
Thanks!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I haven't had time to really review the code here (except to notice
that you have a typo: nedded) but the idea of it seems good.
v3 rebase (after pgbench moved to src/bin) and minor style tweaking.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index
On 04/26/2015 04:08 PM, Noah Misch wrote:
On Sun, Apr 26, 2015 at 10:23:58AM -0400, Andrew Dunstan wrote:
Setting up a VS2008 environment is hard these days, as MS seems to have
removed the download :-(
Visual C++ 2008 Express Edition:
http://go.microsoft.com/?linkid=7729279
Oh, cool.
On Mon, Apr 27, 2015 at 8:53 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/26/2015 04:08 PM, Noah Misch wrote:
On Sun, Apr 26, 2015 at 10:23:58AM -0400, Andrew Dunstan wrote:
Setting up a VS2008 environment is hard these days, as MS seems to have
removed the download :-(
Visual C++
On Sun, Apr 26, 2015 at 10:23:58AM -0400, Andrew Dunstan wrote:
Setting up a VS2008 environment is hard these days, as MS seems to have
removed the download :-(
Visual C++ 2008 Express Edition:
http://go.microsoft.com/?linkid=7729279
--
Sent via pgsql-hackers mailing list
On Sun, Apr 26, 2015 at 6:34 AM, Stephen Frost sfr...@snowman.net wrote:
What's important, in my view, is to keep the simple case simple and so
I'm not particularly wedded to any of these approaches, just trying to
help with other suggestions.
INSERT INTO mytable VALUES
On 19-03-2015 15:13, Robert Haas wrote:
On Wed, Mar 18, 2015 at 5:36 PM, Andres Freund and...@2ndquadrant.com wrote:
Reading the README first, the rest later. So you can comment on my
comments, while I actually look at the code. Parallelism, yay!
I'm also looking at this piece of code and
* Peter Geoghegan (p...@heroku.com) wrote:
On Sun, Apr 26, 2015 at 11:08 AM, Stephen Frost sfr...@snowman.net wrote:
I don't want to accept something that automatically merges the
excluded tuple (e.g., SET (*) = EXLCUDED.*), for reasons outlined
here:
* Peter Geoghegan (p...@heroku.com) wrote:
On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost sfr...@snowman.net wrote:
Ok, that makes sense.. So is the concern that an INSERT would end up
getting default values while an UPDATE would preserve whatever's there?
I don't see that as an issue.
On 2015-04-26 12:53:30 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-04-26 19:13:42 +0400, Dmitriy Olshevskiy wrote:
- * therefor it is up to the calling routine to
+ * therefore it is up to the calling routine to
I think both are actually
Andres Freund and...@anarazel.de writes:
On 2015-04-26 12:53:30 -0400, Tom Lane wrote:
Hm. My dictionary says that therefor is archaic, but to my eye it
looks just wrong. Certainly no modern writer would spell it like that.
Mine said that it's still common in some circles, particularly the
* Álvaro Hernández Tortosa (a...@8kdata.com) wrote:
It's worth document but also, as I said, maybe also fixing them,
so that if three years from now they really show up, solution is
already in production (rather than in patching state).
With the proliferation of JSON usage in PG thanks to
On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost sfr...@snowman.net wrote:
Ok, that makes sense.. So is the concern that an INSERT would end up
getting default values while an UPDATE would preserve whatever's there?
I don't see that as an issue.
I think it easily could be.
Are you still
On 2015-04-26 13:03:52 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-04-26 12:53:30 -0400, Tom Lane wrote:
Hm. My dictionary says that therefor is archaic, but to my eye it
looks just wrong. Certainly no modern writer would spell it like that.
Mine said that
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
On Sun, Apr 26, 2015 at 6:34 AM, Stephen Frost sfr...@snowman.net wrote:
What's important, in my view, is to keep the simple case simple and so
I'm not particularly wedded to any of these approaches, just trying to
help with other
On Sun, Apr 26, 2015 at 11:08 AM, Stephen Frost sfr...@snowman.net wrote:
I don't want to accept something that automatically merges the
excluded tuple (e.g., SET (*) = EXLCUDED.*), for reasons outlined
here: https://wiki.postgresql.org/wiki/UPSERT#VoltDB.27s_UPSERT
Perhaps I'm missing it,
J.L.,
* jltal...@adv-solutions.net (jltal...@adv-solutions.net) wrote:
Any suggestions on how to do it properly?
Does Greg Stark's suggestion (at
CAM-w4HPOASwsQMdGZqjyFHNubbUnWrUAo8ibci-97UKU=po...@mail.gmail.com)
make sense to you?
This approach might suffer from the same problem as mine,
On Sun, Apr 26, 2015 at 11:43 AM, Stephen Frost sfr...@snowman.net wrote:
I think it easily could be.
Ok.. Can you elaborate on that? Would it be an issue that's different
from the same thing done as independent commands?
I think that the stuff I linked to describes my concerns
I have pushed my patch, newly rebased, to a new branch on my personal
Github account (branch: insert_conflict_4):
https://github.com/petergeoghegan/postgres/commits/insert_conflict_4
I'm not going to attach a patch here at all. Andres and Heikki should
now push their changes to that branch (or
The attached patch v13 is revised one according to the suggestion
by Robert.
- eliminated useless change in allpaths.c
- eliminated an extra space in FdwRoutine definition
- prohibited to have scanrelid==0 by other than ForeignScan
or CustomScan, using Assert()
- definition of currentRelation
On 2015-04-25 AM 04:20, Tom Lane wrote: *
It's not a typo; the comment was correct when written. But I evidently
missed updating it when set_append_rel_pathlist() got split into two
functions. Applied, thanks for noticing!
Ah, thanks!
Amit
--
Sent via pgsql-hackers mailing
On Sun, Apr 26, 2015 at 6:02 PM, Peter Geoghegan p...@heroku.com wrote:
Remaining challenges
=
I may have forgotten one: Andres asked me to make logical decoding
discriminate against speculative confirmation records/changes, as
opposed to merely looking for the absence of a
On 2015-04-22 AM 04:14, Robert Haas wrote:
We should check IsParallelWorker() for operations that are allowed in
the master during parallel mode, but not allowed in the workers - e.g.
the master can scan its own temporary relations, but its workers
can't. We should check IsInParallelMode()
37 matches
Mail list logo
