Hi,
I noticed that there is no postgres_fdw option to control whether check
constraints on remote tables are included in the definitions of foreign
tables imported from a remote PG server when performing IMPORT FOREIGN
SCHEMA, while we now allow check constraints on foreign tables.
Attached is a
Here is a patch to add missing tab-completion for ALTER FOREIGN TABLE.
I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 1128,1134 psql_completion(const char *text, int start, int end)
On Mon, Apr 27, 2015 at 3:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Hi,
I noticed that there is no postgres_fdw option to control whether check
constraints on remote tables are included in the definitions of foreign
tables imported from a remote PG server when performing IMPORT
Remove pgbench constraint that the number of clients must be a multiple of
the number of threads, by sharing clients among threads as evenly as
possible.
Rational: allows to test the database load with any number of client
without unrelated constraint. The current setting means for instance
On 4/27/15 11:47 AM, Joel Jacobson wrote:
On Mon, Apr 27, 2015 at 6:14 PM, Marko Tiikkaja ma...@joh.to
mailto:ma...@joh.to wrote:
That sounds weird. log_min_messages are the messages sent to the
log; client_min_messages are sent to the client.
context_min_messages are not sent to a
On 4/25/15 12:12 AM, Amit Kapila wrote:
... which isn't possible. You can not go from a heap tuple to an
index tuple.
We will have the access to index value during delete, so why do you
think that we need linkage between heap and index tuple to perform
Delete operation? I think we need to
On 4/25/15 7:49 PM, Dave Jones wrote:
I've been working on a conversion of several utilities I wrote for
another engine, and was wondering if there was any interest in seeing
any of them added to contrib/ at some point in the vague undefined future?
Not in contrib, no, because there's no
On 4/25/15 6:30 AM, Simon Riggs wrote:
On 24 April 2015 at 22:36, Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com wrote:
Instead of adding forcefsm, I think it would be more useful to
accept a target block number. That way we can actually control where
the new
On 2015-04-27 16:28:49 +0200, Andres Freund wrote:
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
* So far, there has been a lack of scrutiny about what the patch does
in the rewriter (in particular, to support the EXCLUDED.* pseudo-alias
expression) and optimizer (the whole concept
On 4/25/15 2:05 PM, Peter Geoghegan wrote:
Note that the syntax is quite similar to the SQLite
syntax of the same feature, that has ON CONFLICT IGNORE (it also has
ON CONFLICT REPLACE, but not ON CONFLICT UPDATE).
I don't know anything about SQLite's syntax, but from the online syntax
diagrams
On 2015/04/27 15:51, Michael Paquier wrote:
On Mon, Apr 27, 2015 at 3:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I noticed that there is no postgres_fdw option to control whether check
constraints on remote tables are included in the definitions of foreign
tables imported from a
Hi Ashutosh,
Thanks for the review.
2015/04/22 19:28、Ashutosh Bapat ashutosh.ba...@enterprisedb.com のメール：
Tests
---
1.The postgres_fdw test is re/setting enable_mergejoin at various places. The
goal of these tests seems to be to test the sanity of foreign plans
generated. So, it might
On 4/25/15 1:19 PM, Bruce Momjian wrote:
Note if you are storing a table with rows that exceed 2KB in size
(aggregate size of each row) then the Maximum number of rows in a
table may be limited to 4 Billion, see TOAST.
That's not accurate though; you could be limited to
On Sat, Apr 25, 2015 at 11:36 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan and...@dunslane.net wrote:
The optional buildfarm module that runs this test was broken by commit
dcae5faccab64776376d354decda0017c648bb53
Since nobody has
On Mon, Apr 27, 2015 at 9:20 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
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
On 4/27/15, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/25/15 1:19 PM, Bruce Momjian wrote:
Note if you are storing a table with rows that exceed 2KB in size
(aggregate size of each row) then the Maximum number of rows in a
table may be limited to 4 Billion, see TOAST.
On 04/27/2015 02:39 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 11:36 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan and...@dunslane.net wrote:
The optional buildfarm module that runs this test was broken by commit
On Mon, Apr 27, 2015 at 4:20 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On 2015/04/27 15:51, Michael Paquier wrote:
On Mon, Apr 27, 2015 at 3:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I noticed that there is no postgres_fdw option to control whether check
constraints
On Mon, Apr 27, 2015 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/27/15 2:09 AM, Michael Paquier wrote:
2) I noticed that VC builds do not like *at all* file paths with
forward slashes, perhaps it could be possible to use a Condition like
hasForwardSlashes but it seems safer to
On Mon, Apr 27, 2015 at 9:28 PM, Andrew Dunstan wrote:
The patch needed a little adjustment so it runs with the right switches in
the right branch, I think. See
https://github.com/PGBuildFarm/client-code/commit/2176bba516f9effd17fceec45e93218ef8a21e8d
Oops, yes. Updated as well...
--
Michael
On 4/27/15 2:09 AM, Michael Paquier wrote:
2) I noticed that VC builds do not like *at all* file paths with
forward slashes, perhaps it could be possible to use a Condition like
hasForwardSlashes but it seems safer to simply enforce the file paths
to use backslashes in the vcproj files. That's
On Sat, Apr 25, 2015 at 3:40 AM, David Steele da...@pgmasters.net wrote:
On 4/4/15 9:21 AM, Sawada Masahiko wrote:
I added documentation changes to patch is attached.
Also I tried to use memory context for allocation of guc_file_variable
in TopMemoryContext,
but it was failed access after
On 04/27/2015 08:46 AM, Michael Paquier wrote:
On Mon, Apr 27, 2015 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/27/15 2:09 AM, Michael Paquier wrote:
2) I noticed that VC builds do not like *at all* file paths with
forward slashes, perhaps it could be possible to use a Condition
Looks good Pavel!
May I just suggest you add the default case
to src/test/regress/sql/plpgsql.sql
and src/test/regress/expected/plpgsql.out, to make it easier for the
reviewer to compare the difference between what happens in the default
case, when not using the raise-syntax and not using the
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
It's make-or-break time for this patch. Please help me get it over the
line in time.
Could you please add the tests for the logical decoding code you added?
I presume you have some already/
Heikki is in Northern California this week, and I
2015-04-27 16:05 GMT+02:00 Joel Jacobson j...@trustly.com:
Looks good Pavel!
May I just suggest you add the default case
to src/test/regress/sql/plpgsql.sql
and src/test/regress/expected/plpgsql.out, to make it easier for the
reviewer to compare the difference between what happens in the
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
* So far, there has been a lack of scrutiny about what the patch does
in the rewriter (in particular, to support the EXCLUDED.* pseudo-alias
expression) and optimizer (the whole concept of an auxiliary
query/plan that share a target RTE, and
On Sat, Apr 25, 2015 at 11:11:52PM -0400, Tom Lane wrote:
Hm, good point; INHERITS will silently override such a specification:
regression=# create table base1 (f1 int) with oids;
CREATE TABLE
regression=# create table c2 () inherits (base1) without oids;
CREATE TABLE
regression=# \d+ c2
On 04/27/2015 12:46 PM, Petr Jelinek wrote:
Another thing I noticed now when reading the code again - you should
not be using braces when you only have one command in the code-block.
There's one exception I, at least, have to this rule, namely when
there's a corresponding compound if or
This patch removes the pgbench thread fork-emulation code and simplifies
things where possible, especially around pthread_create and pthread_join.
The stats collection for the report is done directly instead of using an
intermediate structure.
As a result, if no thread implementation is
Hi Jim,
On 27/04/15 21:48, Jim Nasby wrote:
On 4/25/15 7:49 PM, Dave Jones wrote:
I've been working on a conversion of several utilities I wrote for
another engine, and was wondering if there was any interest in seeing
any of them added to contrib/ at some point in the vague undefined
On Mon, Apr 27, 2015 at 1:19 PM, Peter Eisentraut pete...@gmx.net wrote:
it appears that they are using quite a different syntax. The ON
CONFLICT clause is attached to a constraint, specifying the default
action for that constraint. The INSERT command can then override this
default choice.
On 4/27/15 6:08 PM, Dave Jones wrote:
(Though, I dislike using timestamps to do change/history tracking, but
that's just me...)
I've been playing around with history tracking (in the context of BI,
typically with batch loaded reporting databases) for about 7-8 years now
and always found
On 4/25/15 4:50 PM, Tom Lane wrote:
Well, we already support local variables of type RECORD in plpgsql, so
it's not immediately clear to me that function arguments would be much
worse. There are a lot of deficiencies with the RECORD-local-variable
implementation: if you try to change the actual
On Mon, Apr 27, 2015 at 4:21 PM, Peter Geoghegan p...@heroku.com wrote:
* Don't change the ON CONFLICT spelling.
* Don't change the names of the pseudo-alias EXCLUDED.* (or the alias
TARGET.*). Those seem fine to me as well.
* Change the syntax to put the WHERE clause used to infer partial
On Sun, Apr 26, 2015 at 6:02 PM, Peter Geoghegan p...@heroku.com wrote:
* I privately pointed out to Heikki what I'd said publicly about 6
weeks ago: that there is still a *very* small chance of exclusion
constraints exhibiting unprincipled deadlocks (he missed it at the
time). I think that
On 04/27/2015 10:35 PM, Jim Nasby wrote:
On 4/25/15 4:50 PM, Tom Lane wrote:
Well, we already support local variables of type RECORD in plpgsql, so
it's not immediately clear to me that function arguments would be much
worse. There are a lot of deficiencies with the RECORD-local-variable
On 04/27/2015 07:02 PM, Peter Geoghegan wrote:
So, this can still happen, but is now happening less often than
before, I believe. On a 16 core server, with continual 128 client
jjanes_upsert exclusion constraint only runs, with fsync=off, I
started at this time:
2015-04-27 21:22:28 UTC [ 0 ]:
On Mon, Apr 27, 2015 at 7:02 PM, Peter Geoghegan p...@heroku.com wrote:
Given that exclusion constraints can only be used with IGNORE, and
given that this is so hard to recreate, I'm inclined to conclude that
it's acceptable. It's certainly way better than risking livelocks by
not having
On Tue, Apr 28, 2015 at 3:22 AM, David Steele da...@pgmasters.net wrote:
On 4/27/15 10:31 AM, Sawada Masahiko wrote:
Thank you for your review comment!
The latest patch is attached.
Looks good overall - a few more comments below:
Thank you for your reviewing.
Attached v8 patch is latest
At 2015-01-30 21:36:42 +0100, and...@2ndquadrant.com wrote:
Here's an alternative approach. I think it generally is superior and
going in the right direction, but I'm not sure it's backpatchable.
It basically consists out of:
1) Make GetLockConflicts() actually work.
already
On Mon, Apr 27, 2015 at 11:31 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sat, Apr 25, 2015 at 3:40 AM, David Steele da...@pgmasters.net wrote:
On 4/4/15 9:21 AM, Sawada Masahiko wrote:
I added documentation changes to patch is attached.
Also I tried to use memory context for
On 4/27/15 6:08 PM, Fabrízio de Royes Mello wrote:
On Sun, Apr 26, 2015 at 4:19 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
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.
What you think
On Sat, Apr 25, 2015 at 7:23 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Sat, Apr 25, 2015 at 7:59 AM, Peter Eisentraut pete...@gmx.net wrote:
On 4/23/15 1:22 PM, Jeff Janes wrote:
Something about this commit (dcae5faccab64776376d354d) broke make
check in parallel conditions
On Sun, Apr 26, 2015 at 4:19 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
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.
What you think just context_min_messages ?
Regards,
--
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
I took another look at this and came up with some alternate comment
rewording. I also added a couple of additional comments that should
hopefully clarify the code a bit.
Finally got back to this. Made a few additional changes that made
On Mon, Apr 27, 2015 at 6:14 PM, Marko Tiikkaja ma...@joh.to wrote:
That sounds weird. log_min_messages are the messages sent to the log;
client_min_messages are sent to the client. context_min_messages are not
sent to a context, whatever that would mean.
Good point.
I think it can't be
On 18/04/15 20:35, Dmitry Dolgov wrote:
Sorry for late reply. Here is a slightly improved version of the patch
with the new `h_atoi` function, I hope this implementation will be more
appropriate.
It's better, but a) I don't like the name of the function b) I don't see
why we need the
On Mon, Apr 27, 2015 at 10:20 AM, Bruce Momjian br...@momjian.us wrote:
Agreed, and I like the DO [ UPDATE | NOTHING ] too.
Here is what I think I need to do:
* Don't change the ON CONFLICT spelling.
* Don't change the names of the pseudo-alias EXCLUDED.* (or the alias
TARGET.*). Those seem
On Sun, Apr 26, 2015 at 09:34:12AM -0400, Stephen Frost wrote:
* 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
Bruce, all,
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases.
Bruce Momjian wrote:
Agreed. Here is an attached patch for 9.6 which works for multiple
LIKE'ed tables with multiple inheritance and index creation. I figured
out why Tom's OID primary key test was failing so I now process the
columns and LIKE first, then the constraints. There is also no
On Mon, Apr 27, 2015 at 2:52 PM, Andres Freund and...@anarazel.de wrote:
So, I'm looking. And I've a few questions:
* Why do we need to spread knowledge about speculative inserts that wide?
It's now in 1) Query, 2) ParseState 3) ModifyTable 4) InsertStmt. That
seems a bit wide - and as far
On 4/27/15 10:31 AM, Sawada Masahiko wrote:
Thank you for your review comment!
The latest patch is attached.
Looks good overall - a few more comments below:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
+row
+ entrystructfieldseqno/structfield/entry
+
54 matches
Mail list logo
