On Mon, Apr 27, 2015 at 3:15 PM, Etsuro Fujita
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 FOREIGN
> SCHEMA, while
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)
pg_str
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 t
On Sat, Apr 25, 2015 at 11:36 PM, Michael Paquier
wrote:
> On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan wrote:
>> The optional buildfarm module that runs this test was broken by commit
>> dcae5faccab64776376d354decda0017c648bb53
>>
>> Since nobody has responded to my complaint about this, I ha
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
On Mon, Apr 27, 2015 at 9:20 AM, Michael Paquier
wrote:
> On Mon, Apr 27, 2015 at 8:53 AM, Andrew Dunstan 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
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 in
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 IsInParallelMod
On Sun, Apr 26, 2015 at 6:02 PM, Peter Geoghegan 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 super-deletion. We
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 al
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 mail
On Mon, Apr 27, 2015 at 8:53 AM, Andrew Dunstan 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++ 2
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. Thank
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 (pgsql-hackers@pos
On Sun, Apr 26, 2015 at 11:43 AM, Stephen Frost 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 exhaustively.
In any case,
* Peter Geoghegan (p...@heroku.com) wrote:
> On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost 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 thi
On Sun, Apr 26, 2015 at 11:35 AM, Stephen Frost 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 against having a
* Peter Geoghegan (p...@heroku.com) wrote:
> On Sun, Apr 26, 2015 at 11:08 AM, Stephen Frost 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
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
> )
> make sense to you?
> This approach might suffer from the same problem as mine, though.
Well, Greg's suggestion was intended to specifically
On Sun, Apr 26, 2015 at 11:08 AM, Stephen Frost 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, but the rea
* Á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 t
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> On Sun, Apr 26, 2015 at 6:34 AM, Stephen Frost 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.
> >
> >
On 19-03-2015 15:13, Robert Haas wrote:
> On Wed, Mar 18, 2015 at 5:36 PM, Andres Freund 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 found some low-hangi
On Sun, Apr 26, 2015 at 6:34 AM, Stephen Frost 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 ('key1','key2','val1','val2')
> ON C
On 2015-04-26 13:03:52 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 law,
> so I
On 2015-04-26 12:53:30 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 dictionary says that
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
> --- a/src/ba
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 datab
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 th
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=currawong&dt=2015-04-26%2006%3A00%3A01
The build is done in Debug mode, but it is failing
* 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
Andres Freund 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 would apply to an
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 06a4dfd..3
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 b/d
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
On 26/04/15 12:08, Andres Freund wrote:
On April 26, 2015 11:22:01 AM GMT+02:00, Heikki Linnakangas
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 action, to
avoid
On April 26, 2015 11:22:01 AM GMT+02:00, Heikki Linnakangas
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) differen
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 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 :
> Hi
>
> 2015-04-24 19:16 GMT+02:00 Joel Jacobson :
>
>> On Fri
On Sun, Apr 26, 2015 at 10:29 AM, Andrew Dunstan wrote:
>
> On 04/25/2015 08:01 PM, Michael Paquier wrote:
>>
>> On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan
>> wrote:
>>>
>>> On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
43 matches
Mail list logo
