Re: Postgres 11: Table Partitioning and Primary Keys

2019-07-09 Thread David G. Johnston
On Mon, Jul 8, 2019 at 11:34 PM Michael Paquier wrote: > On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote: > > Reads a bit backward. How about: > > > > "As uniqueness can only be enforced within an individual partition when > > defining a primary key on a partitioned table all c

Re: Postgres 11: Table Partitioning and Primary Keys

2019-07-09 Thread Amit Langote
Sorry for jumping in late here. On Tue, Jul 9, 2019 at 3:51 PM Michael Paquier wrote: > On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote: > > Looking closely at the code in DefineIndex() (and as Rajkumar has > > mentioned upthread for unique constraints) this can happen for primary

Re: Ambiguous language in Table 8.13. Special Date/Time Inputs [EXT]

2019-07-09 Thread David Harper
> Uh, I believe midnight is always the start of the day. The U.S. National Institute of Standards and Technology (NIST) deprecates the term “midnight” as ambiguous and recommmends the use of 24-hour clock notation: = BEGIN QUOTE = When someone refers to "midnight tonight" or "midnight la

Re: Ambiguous language in Table 8.13. Special Date/Time Inputs [EXT]

2019-07-09 Thread Bruce Momjian
On Tue, Jul 9, 2019 at 09:14:27AM +0100, David Harper wrote: > > Uh, I believe midnight is always the start of the day. > > The U.S. National Institute of Standards and Technology (NIST) deprecates the > term “midnight” as ambiguous and recommmends the use of 24-hour clock > notation: > >

Re: Ambiguous language in Table 8.13. Special Date/Time Inputs [EXT]

2019-07-09 Thread Tom Lane
Bruce Momjian writes: > Yes, I see what you mean now. How is this patch, which uses "zero > hour"? Ugh. Are we writing spy novels now? I actually agree with your opinion that "midnight" is fine. That text has been that way for over fifteen years[1], and nobody's complained before that it was a

Re: Improvement of GIN figure

2019-07-09 Thread Peter Geoghegan
On Tue, Jul 9, 2019 at 12:20 AM Oleg Bartunov wrote: > Sorry, I may missed the discussion of what colors and fonts we accept > for our documentation, but > the color and fonts used I don't like. I attached our version of GIN figure. I agree that the existing colors look awful, and that muted past

Re: Improvement of GIN figure

2019-07-09 Thread Tatsuo Ishii
> I agree that the existing colors look awful, and that muted pastel > colors would work better. Doesn't seem like something that should > happen at the cost of making the diagram less informative, though. I am not an expert in the area but I think we should cosider people with color disability.

Re: Improvement of GIN figure

2019-07-09 Thread Peter Geoghegan
On Tue, Jul 9, 2019 at 3:22 PM Tatsuo Ishii wrote: > > I agree that the existing colors look awful, and that muted pastel > > colors would work better. Doesn't seem like something that should > > happen at the cost of making the diagram less informative, though. > > I am not an expert in the area

Re: Postgres 11: Table Partitioning and Primary Keys

2019-07-09 Thread Alvaro Herrera
On 2019-Jul-09, Amit Langote wrote: > As mentioned in the docs, defining exclusion constraints on > partitioned tables is not supported. Right. > "While defining a primary key and unique constraints on partitioned > tables is supported, the set of columns being constrained must include > all of

Re: Postgres 11: Table Partitioning and Primary Keys

2019-07-09 Thread Tom Lane
Alvaro Herrera writes: > That's a mild personal preference only though. Anyway, based on your > proposed wording, I wrote this: > > >Unique constraints on partitioned tables (as well as primary keys) >must constrain all the partition key columns. This limitation exi

Re: Postgres 11: Table Partitioning and Primary Keys

2019-07-09 Thread Amit Langote
On Wed, Jul 10, 2019 at 7:53 AM Alvaro Herrera wrote: > On 2019-Jul-09, Amit Langote wrote: > > "While defining a primary key and unique constraints on partitioned > > tables is supported, the set of columns being constrained must include > > all of the partition key columns. This limitation exis