Tom, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> Alright, here's an updated patch which cleans things up a bit and adds
> comments to explain what's going on. I also updated the comments in
> acl.h to explain that ordering actually does matter.
Getting back to this, here's rebased patches
Tom, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> This needs more cleanup, testing, and comments explaining why we're
> doing this (and then perhaps comments, somewhere.. in the backend ACL
> code that explains that the ordering needs to be preserved), but the
> basic idea seems sound to me
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> AFAICT, pg_dump has no notion that it needs to be careful about the order
> >> in which permissions are granted. I did
>
> > I'm afraid that's correct, though I believe that's alw
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> AFAICT, pg_dump has no notion that it needs to be careful about the order
>> in which permissions are granted. I did
> I'm afraid that's correct, though I believe that's always been the case.
> I spent some time looking into this
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> AFAICT, pg_dump has no notion that it needs to be careful about the order
> in which permissions are granted. I did
I'm afraid that's correct, though I believe that's always been the case.
I spent some time looking into this today and from what I've
... btw, while you're working on this, it'd be nice if you fixed the
header comment for dumpACL(). It is unintelligible as to what racls
is, and apparently feels that it need not discuss initacls or initracls
at all. I can't say that the reference to "fooacl" is really obvious
either.
Hello,
25.07.2017, 11:17, "Victor Drobny" :
>
> Hello,
>
> Do you expect to have some flag like '--rename=test->test2'?
Yes, I do.
> Will dump with test replaced by test2(of course only in related places)
> be valid dump in this case?
Yes, it will.
> What is the possible scenario for the ren
On 07/26/2017 02:12 AM, Tom Lane wrote:
AFAICT, pg_dump has no notion that it needs to be careful about the order
in which permissions are granted. I did
regression=# create user joe;
CREATE ROLE
regression=# create user bob;
CREATE ROLE
regression=# create user alice;
CREATE ROLE
regression=#
Stephen Frost writes:
> On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote:
>> I should point out that this commit was made during the 9.6 cycle, and
>> I get the same issue with 9.6.
> Interesting that Tom didn't. Still, that does make more sense to me.
Yeah, it makes more sense to me too, but non
Thom,
On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote:
> On 26 July 2017 at 00:52, Stephen Frost wrote:
> > Thom,
> >
> > * Thom Brown (t...@linux.com) wrote:
> >> This is the culprit:
> >>
> >> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> >> Author: Stephen Frost
> >> Date: Wed Apr 6 21
On 26 July 2017 at 00:52, Stephen Frost wrote:
> Thom,
>
> * Thom Brown (t...@linux.com) wrote:
>> This is the culprit:
>>
>> commit 23f34fa4ba358671adab16773e79c17c92cbc870
>> Author: Stephen Frost
>> Date: Wed Apr 6 21:45:32 2016 -0400
>
> Thanks! I'll take a look tomorrow.
I should point o
Thom,
* Thom Brown (t...@linux.com) wrote:
> This is the culprit:
>
> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> Author: Stephen Frost
> Date: Wed Apr 6 21:45:32 2016 -0400
Thanks! I'll take a look tomorrow.
Stephen
signature.asc
Description: Digital signature
On 25 July 2017 at 21:47, Stephen Frost wrote:
> Tom,
>
> On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote:
>>
>> AFAICT, pg_dump has no notion that it needs to be careful about the order
>> in which permissions are granted. I did
>>
>> regression=# create user joe;
>> CREATE ROLE
>> regression=# cr
Tom,
On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote:
> AFAICT, pg_dump has no notion that it needs to be careful about the order
> in which permissions are granted. I did
>
> regression=# create user joe;
> CREATE ROLE
> regression=# create user bob;
> CREATE ROLE
> regression=# create user alice
AFAICT, pg_dump has no notion that it needs to be careful about the order
in which permissions are granted. I did
regression=# create user joe;
CREATE ROLE
regression=# create user bob;
CREATE ROLE
regression=# create user alice;
CREATE ROLE
regression=# \c - joe
You are now connected to database
We can't create any schema dump with another (user defined) name. E.g.
we dump schema test and we want to save it's dump with test2 name in
any format. Those refers to databases dump.
Hello,
Do you expect to have some flag like '--rename=test->test2'?
Will dump with test replaced by test2(of co
On 6 June 2017 at 11:37, Дмитрий Воронин wrote:
> Hello,
>
> We are working on one project with postgres as engeneer.
>
> Bellow is list of inconveniences that we are having with postgresql. We
> would like to solve them as possible.
>
> We can't create any schema dump with another (user defined)
Hello,We are working on one project with postgres as engeneer.Bellow is list of inconveniences that we are having with postgresql. We would like to solve them as possible.We can't create any schema dump with another (user defined) name. E.g. we dump schema test and we want to save it's dump with te
2017-05-26 17:52 GMT-03:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
>
> You cannot publish a system catalog. But a user-created table in
> information_schema is not a system catalog.
Replication of information_schema tables works. However, pg_dump doesn't
include information_schema
On 5/25/17 22:45, Robert Haas wrote:
> I guess I'm not convinced that it's really the same. I think we want
> to allow users to create views over system objects; our life might be
> easier if we hadn't permitted that, but views over e.g. pg_locks are
> common, and prohibiting them doesn't seem lik
On Thu, May 25, 2017 at 5:06 PM, Peter Eisentraut
wrote:
> They are the same cases.
>
> a) Create object in information_schema.
>
> b) Create another object elsewhere that depends on it.
>
> c) pg_dump will dump (b) but not (a).
>
> So the fix, if any, would be to prevent (a), or prevent (b), or f
On 5/25/17 09:55, Robert Haas wrote:
> On Thu, May 25, 2017 at 8:32 AM, Peter Eisentraut
> wrote:
>>> Well, I think if it's not going to work, it should be prohibited,
>>> rather than seeming to work but then not actually working.
>>
>> Here is a similar case that pg_dump fails on:
>>
>> create ta
On Thu, May 25, 2017 at 8:32 AM, Peter Eisentraut
wrote:
>> Well, I think if it's not going to work, it should be prohibited,
>> rather than seeming to work but then not actually working.
>
> Here is a similar case that pg_dump fails on:
>
> create table information_schema.test1 (a int);
> create
On 5/24/17 21:36, Robert Haas wrote:
> On Wed, May 24, 2017 at 7:16 PM, Peter Eisentraut
> wrote:
>> On 5/22/17 07:42, Kuntal Ghosh wrote:
>>> pg_dump ignores anything created under object name "pg_*" or
>>> "information_schema".
>>
>> Publications have a slightly different definition of what tabl
On Wed, May 24, 2017 at 7:16 PM, Peter Eisentraut
wrote:
> On 5/22/17 07:42, Kuntal Ghosh wrote:
>> pg_dump ignores anything created under object name "pg_*" or
>> "information_schema".
>
> Publications have a slightly different definition of what tables to
> ignore/prohibit than pg_dump, partly b
On 5/22/17 07:42, Kuntal Ghosh wrote:
> pg_dump ignores anything created under object name "pg_*" or
> "information_schema".
Publications have a slightly different definition of what tables to
ignore/prohibit than pg_dump, partly because they have more built-in
knowledge. I'm not sure whether it'
On Mon, May 22, 2017 at 5:22 PM, tushar wrote:
> On 05/22/2017 05:12 PM, Kuntal Ghosh wrote:
>>
>> pg_dump ignores anything created under object name "pg_*" or
>> "information_schema".
>
> In this below scenario , I am able to see - pg_dump catch the information
> of table which is created under
On 05/22/2017 05:31 PM, Tom Lane wrote:
Do we have a prohibition against publishing/subscribing anything
in pg_catalog?
Yes.
postgres=# create publication pub for table pg_catalog.pg_AM;
ERROR: "pg_am" is a system table
DETAIL: System tables cannot be added to publications.
postgres=#
--
reg
tushar writes:
> On 05/22/2017 05:12 PM, Kuntal Ghosh wrote:
>> pg_dump ignores anything created under object name "pg_*" or
>> "information_schema".
> In this below scenario , I am able to see - pg_dump catch the
> information of table which is created under information_schema
Creating your o
On 05/22/2017 05:12 PM, Kuntal Ghosh wrote:
pg_dump ignores anything created under object name "pg_*" or
"information_schema".
In this below scenario , I am able to see - pg_dump catch the
information of table which is created under information_schema
postgres=# create database ntest;
\CREAT
Hello,
pg_dump ignores anything created under object name "pg_*" or
"information_schema". I guess you will not have any "CREATE TABLE"
definition as well for information_schema.abc. Related code:
else if (strncmp(nsinfo->dobj.name, "pg_", 3) == 0 ||
strcmp(nsinfo->dobj.name, "inform
Hi,
pg_dump is ignoring tables which created under information_schema
schema for CREATE PUBLICATION .
postgres=# create database test;
CREATE DATABASE
postgres=# \c test
You are now connected to database "test" as user "centos".
test=# create table information_schema.abc(n int);
CREATE TABL
FWIW I ended up reverting the whole thing, even from master. A more
complete solution would have to be researched.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
On 2017/05/08 12:42, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> Thanks for committing the patch after improving it quite a bit, and sorry
>> that I couldn't reply promptly during the last week due to vacation.
>
> No worries, hopefully you have an op
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Thanks for committing the patch after improving it quite a bit, and sorry
> that I couldn't reply promptly during the last week due to vacation.
No worries, hopefully you have an opportunity to review the additional
changes I made and
Hi Stephen,
On 2017/05/06 12:28, Stephen Frost wrote:
> Noah,
>
> On Fri, May 5, 2017 at 23:19 Noah Misch wrote:
>
>> On Thu, May 04, 2017 at 05:47:02PM -0400, Stephen Frost wrote:
>>> * Amit Langote (amitlangot...@gmail.com) wrote:
On Wed, May 3, 2017 at 12:05 PM, Stephen Frost
>> wrote:
Noah,
On Fri, May 5, 2017 at 23:19 Noah Misch wrote:
> On Thu, May 04, 2017 at 05:47:02PM -0400, Stephen Frost wrote:
> > * Amit Langote (amitlangot...@gmail.com) wrote:
> > > On Wed, May 3, 2017 at 12:05 PM, Stephen Frost
> wrote:
> > > > Assuming this looks good to you, I'll push it tomorrow,
On Thu, May 04, 2017 at 05:47:02PM -0400, Stephen Frost wrote:
> * Amit Langote (amitlangot...@gmail.com) wrote:
> > On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote:
> > > Assuming this looks good to you, I'll push it tomorrow, possibly with
> > > other minor adjustments and perhaps a few mor
Amit,
* Amit Langote (amitlangot...@gmail.com) wrote:
> On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote:
> > Assuming this looks good to you, I'll push it tomorrow, possibly with
> > other minor adjustments and perhaps a few more tests.
>
> Your latest patch looks good to me.
Found a few m
Amit,
* Amit Langote (amitlangot...@gmail.com) wrote:
> On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote:
> > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> >> Attached updated patches.
> >
> > Please find an updated version which corrects the issue with
> > binary-upgrade of partiti
Hi Stephen,
On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> Attached updated patches.
>
> Please find an updated version which corrects the issue with
> binary-upgrade of partitioned tables having partitions in other schem
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Attached updated patches.
Please find an updated version which corrects the issue with
binary-upgrade of partitioned tables having partitions in other schemas,
along with a few other minor improvements.
If you could take a look at it,
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Now that WITH OPTIONS is optional even for CREATE TABLE OF, perhaps it
> needs to be mentioned in the release notes?
Doesn't strike me as rising to the level of needing to go into the
release notes, but I won't object if people feel th
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Sorry about the delay.
No worries, I'm just back from being in NY and will take a look at this
tomorrow (wrt the open item, I'll provide a status tomorrow).
Thanks!
Stephen
signature.asc
Description: Digital signature
Hi Stephen,
Sorry about the delay.
On 2017/04/27 23:17, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
So to summarize what the patches do (some of these were posted earlier)
0002: pg_dump: Do not emit WITH OPTIONS keywords with partition's
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Sun, Apr 23, 2017 at 11:58:23PM +, Stephen Frost wrote:
> > The status is simply that I've been considering Robert's comments regarding
> > the documentation and have had a busy weekend. I'll provide an update
> > tomorrow.
>
> This PostgreSQ
On Sun, Apr 23, 2017 at 11:58:23PM +, Stephen Frost wrote:
> Noah, all,
>
> On Sun, Apr 23, 2017 at 19:52 Noah Misch wrote:
>
> > On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> > > On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadbo
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> >> So to summarize what the patches do (some of these were posted earlier)
> >>
> >> 0002: pg_dump: Do not emit WITH OPTIONS keywords with partition's columns
> >
> > I'm trying to understand why this is also different. At least on an
Hi Stephen,
On 2017/04/26 23:31, Stephen Frost wrote:
>>> I looked through
>>> pg_get_partkeydef() and it didn't seem to be particularly expensive to
>>> run, though evidently it doesn't handle being passed an OID that it
>>> doesn't expect very cleanly:
>>>
>>> =# select pg_get_partkeydef(oid) fr
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/04/26 0:42, Stephen Frost wrote:
> > I'm not sure what you mean here. We're always going to call both
> > getInherits() and getPartitions() and run the queries in each, with the
> > way the code is written today. In my experie
Hi Stephen,
On 2017/04/26 0:42, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> I think why getPartitions() is separate from getInherits() and then
>> flagPartitions() separate from flagInhTables() is because I thought
>> originally that mixing the two wo
On Tue, Apr 25, 2017 at 12:26 PM, Stephen Frost wrote:
> Interesting. Seems like the question is really what we mean by "ONLY"
> here. For my 2c, at least, if we can check that all of the partitions
> already have the constraint enforced, such that the only thing we're
> changing is the partitio
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 24, 2017 at 9:17 AM, Stephen Frost wrote:
> > I wonder why the restriction is there, which is probably part of the
> > reason that I'm thinking of phrasing the documentation that way.
> >
> > Beyond a matter of round to-its, is th
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> I think why getPartitions() is separate from getInherits() and then
> flagPartitions() separate from flagInhTables() is because I thought
> originally that mixing the two would be undesirable. In the partitioning
> case, getPartitions(
On Mon, Apr 24, 2017 at 9:17 AM, Stephen Frost wrote:
> I wonder why the restriction is there, which is probably part of the
> reason that I'm thinking of phrasing the documentation that way.
>
> Beyond a matter of round to-its, is there a reason why it couldn't (or
> shouldn't) be supported? I'm
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 21, 2017 at 1:43 AM, Stephen Frost wrote:
> >> + Once
> >> + partitions exist, we do not support using ONLY
> >> to
> >> + add or drop constraints on only the partitioned table.
> >>
> >> I wonder if the following sou
Noah, all,
On Sun, Apr 23, 2017 at 19:52 Noah Misch wrote:
> On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> > On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > > * Noah Misch (n...@leadboat.com) wrote:
> > > > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Fros
On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote:
> > > > I've put up a new patch for review on the thread and
On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote:
> > > I've put up a new patch for review on the thread and plan to commit
> > > that tomorrow, assuming there isn't anything fu
On Fri, Apr 21, 2017 at 1:43 AM, Stephen Frost wrote:
>> + Once
>> + partitions exist, we do not support using ONLY to
>> + add or drop constraints on only the partitioned table.
>>
>> I wonder if the following sounds a bit more informative: Once partitions
>> exist, using ONLY will re
Hi Stephen,
On 2017/04/21 8:43, Stephen Frost wrote:
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2017/04/18 1:43, Stephen Frost wrote:
>>> Please take a look at the attached and let me know your thoughts on it.
>>> I changed the code to complain again regarding TRUNCATE ONLY, sin
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote:
> > I've put up a new patch for review on the thread and plan to commit
> > that tomorrow, assuming there isn't anything further. That should
> > resolve the immediate issue, but I
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/04/18 1:43, Stephen Frost wrote:
> > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> >> OK, I agree. I tweaked the existing bullet point about differences from
> >> traditional inheritance when using ONLY with partition
On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote:
> > > On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost
> > > wrote:
> > > > Sure, though I won't be able to today and I've got s
Hi Stephen,
On 2017/04/18 1:43, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> OK, I agree. I tweaked the existing bullet point about differences from
>> traditional inheritance when using ONLY with partitioned tables.
>
> Please take a look at the att
Noah, all,
* Noah Misch (n...@leadboat.com) wrote:
> On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote:
> > On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> > > Sure, though I won't be able to today and I've got some doubts about the
> > > other patches. I'll have more time tom
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> OK, I agree. I tweaked the existing bullet point about differences from
> traditional inheritance when using ONLY with partitioned tables.
Please take a look at the attached and let me know your thoughts on it.
I changed the code to c
On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> > Sure, though I won't be able to today and I've got some doubts about the
> > other patches. I'll have more time tomorrow though.
>
> OK, cool. I'll mark you down as the owne
Hi Stephen,
On 2017/04/14 0:05, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> So I think I was indeed confused before, and I think you're basically
>> right here, but on one point I think you are not right -- ALTER TABLE
>> ONLY .. CHECK () doesn't work on a t
On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> Sure, though I won't be able to today and I've got some doubts about the
> other patches. I'll have more time tomorrow though.
OK, cool. I'll mark you down as the owner on the open items list.
--
Robert Haas
EnterpriseDB: http://www.ent
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> So I think I was indeed confused before, and I think you're basically
> right here, but on one point I think you are not right -- ALTER TABLE
> ONLY .. CHECK () doesn't work on a table with inheritance children
> regardless of whether the chil
On 2017/04/13 6:22, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote:
>> I'm not following what you're getting at here.
>>
>> There's already a constraint on the table, and ALTER TABLE ONLY doesn't
>> say anything about what happens later on (certainly it doesn't make new
On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote:
> I'm not following what you're getting at here.
>
> There's already a constraint on the table, and ALTER TABLE ONLY doesn't
> say anything about what happens later on (certainly it doesn't make new
> tables created with 'LIKE' have bits omitte
On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote
>> wrote:
>> > Actually, p1 is a partitioned table, so the error. And I realize that
>> > that's a wrong behavior. Currently the check is perform
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote
> wrote:
> > Actually, p1 is a partitioned table, so the error. And I realize that
> > that's a wrong behavior. Currently the check is performed using only the
> > relkind, which is bogus. Spec
On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote
wrote:
> Actually, p1 is a partitioned table, so the error. And I realize that
> that's a wrong behavior. Currently the check is performed using only the
> relkind, which is bogus. Specifying ONLY should cause an error only when
> the table has part
Hi Stephen,
On 2017/04/11 22:12, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2017/04/11 0:26, Robert Haas wrote:
>>> Children can have constraints (including NOT NULL constraints) which
>>> parents lack, and can have a different column order, but m
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/04/11 0:26, Robert Haas wrote:
> > Children can have constraints (including NOT NULL constraints) which
> > parents lack, and can have a different column order, but must have
> > exactly the same column names and types.
>
> Als
On 2017/04/11 0:26, Robert Haas wrote:
> On Sun, Apr 9, 2017 at 10:10 PM, Tom Lane wrote:
>> While I admit that I've not been paying close attention to the whole
>> table partitioning business, I wonder whether we have any clearly written
>> down specification about (a) how much partition member t
On Sun, Apr 9, 2017 at 10:10 PM, Tom Lane wrote:
> While I admit that I've not been paying close attention to the whole
> table partitioning business, I wonder whether we have any clearly written
> down specification about (a) how much partition member tables are allowed
> to deviate schema-wise f
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> While I admit that I've not been paying close attention to the whole
>> table partitioning business, I wonder whether we have any clearly written
>> down specification about (a) how much partition member tables are allowed
>> to dev
Tom, Robert,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > I would appreciate help from other contributors and committers on this
> > open item; pg_dump is not my strong point. In the absence of such
> > help, I will do my best with it. I will set aside time this week to
> >
Robert Haas writes:
> I would appreciate help from other contributors and committers on this
> open item; pg_dump is not my strong point. In the absence of such
> help, I will do my best with it. I will set aside time this week to
> study this and send another update no later than Thursday.
The
On Sun, Apr 9, 2017 at 7:50 PM, Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 10 open item. Robert,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open it
On Wed, Mar 29, 2017 at 05:38:41PM +0900, Amit Langote wrote:
> On 2017/03/29 0:39, Robert Haas wrote:
> > On Tue, Mar 28, 2017 at 6:50 AM, Amit Langote
> > wrote:
> >>> Isn't it bogus that this is generating ALTER TABLE .. SET NOT NULL
> >>> columns at all? You didn't say anything like that when
On 3/26/17 16:09, Tom Lane wrote:
> Peter Eisentraut writes:
>> When reporting an error from a query, pg_dump truncates the reported
>> query to 128 characters (pg_backup_db.c ExecuteSqlCommand()).
>
>> Is this (still) sensible? The kind of queries that pg_dump is running
>> nowadays, I find mys
On 2017/03/29 0:39, Robert Haas wrote:
> On Tue, Mar 28, 2017 at 6:50 AM, Amit Langote
> wrote:
>>> Isn't it bogus that this is generating ALTER TABLE .. SET NOT NULL
>>> columns at all? You didn't say anything like that when setting up the
>>> database, so why should it be there when dumping?
>>
On Tue, Mar 28, 2017 at 6:50 AM, Amit Langote
wrote:
>> Isn't it bogus that this is generating ALTER TABLE .. SET NOT NULL
>> columns at all? You didn't say anything like that when setting up the
>> database, so why should it be there when dumping?
>
> So we should find a way for the NOT NULL con
On 2017/03/27 23:30, Robert Haas wrote:
> On Fri, Feb 17, 2017 at 3:23 AM, Amit Langote
> wrote:
>> In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE
>> command for those schema elements of a table that could not be included
>> directly in the CREATE TABLE command for the
Hi Stephen,
On 2017/03/21 1:40, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2017/02/17 22:32, Stephen Frost wrote:
>>> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER T
On Fri, Feb 17, 2017 at 3:23 AM, Amit Langote
wrote:
> In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE
> command for those schema elements of a table that could not be included
> directly in the CREATE TABLE command for the table.
>
> For example:
>
> create table p (a i
Peter Eisentraut writes:
> When reporting an error from a query, pg_dump truncates the reported
> query to 128 characters (pg_backup_db.c ExecuteSqlCommand()).
> Is this (still) sensible? The kind of queries that pg_dump is running
> nowadays, I find myself unable to debug them if they are trunc
When reporting an error from a query, pg_dump truncates the reported
query to 128 characters (pg_backup_db.c ExecuteSqlCommand()).
Is this (still) sensible? The kind of queries that pg_dump is running
nowadays, I find myself unable to debug them if they are truncated at
that length.
--
Peter Ei
At the conclusion of
, pg_upgrade was
changed to upgrade sequences "logically". We initially did that by
adding a pg_dump option --sequence-data that would dump sequence data
(setval calls) in spite of --schema-only. Later, that option was
removed as a separate option and made automatic in --bina
On Wed, Mar 22, 2017 at 7:00 AM, Michael Paquier
wrote:
> On Wed, Mar 22, 2017 at 6:24 AM, Andrew Dunstan
> wrote:
>> This is really a pretty small patch all things considered, and pretty
>> low-risk (although I haven;t been threough the code in fine detail yet).
>> In the end I'm persuaded by An
On Wed, Mar 22, 2017 at 6:24 AM, Andrew Dunstan
wrote:
> This is really a pretty small patch all things considered, and pretty
> low-risk (although I haven;t been threough the code in fine detail yet).
> In the end I'm persuaded by Andres' point that there's actually no
> practical alternative way
On 03/04/2017 01:08 AM, Robert Haas wrote:
> On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier
> wrote:
>> On Thu, Mar 2, 2017 at 2:26 AM, David Steele wrote:
>>> This patch is in need of a committer. Any takers?
>>> I didn't see a lot of enthusiasm from committers on the thread
>> Stephen at le
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/02/17 22:32, Stephen Frost wrote:
> > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> >> In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE
> >> command for those schema elements of a table that c
On 3/6/17 03:06, Amit Langote wrote:
> pg_dump segfaults if there are more than one DO_PUBLICATION_REL objects to
> dump.
Fix committed with a test case. Thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
pg_dump segfaults if there are more than one DO_PUBLICATION_REL objects to
dump.
create table foo (a int);
create publication foo_pub;
alter publication foo_pub add table foo;
$ pg_dump
create table bar (a int);
alter publication foo_pub add table bar;
$ pg_dump -s
Segmentation fault (cor
1 - 100 of 1938 matches
Mail list logo
