Re: [HACKERS] multi-column range partition constraint - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] multi-column range partition constraint
Date
Msg-id CA+Tgmoa=PcJ_yBRkZttteWQkJPftYeC0B4LCQ2k46UB5DNeKQg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] multi-column range partition constraint  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: [HACKERS] multi-column range partition constraint  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Sat, May 13, 2017 at 12:42 AM, Amit Langote <amitlangote09@gmail.com> wrote:
> Attached is the correct version.

Thank you!  I committed 0001 with a couple of cosmetic tweaks and with
the change I previously suggested around partexprs_item.  You argued
that wouldn't work because the contents of partexprs_item was
modified, but that's not so: partexprs_item in
get_range_key_properties is a pointer the partexprs_item in the
caller.  When it modifies *partexprs_item, it's not changing the
contents of the ListCell itself, just the caller's ListCell *.  I also
ran pgindent over the patch.

Also committed 0002.  In that case, I removed CHECK (...) from the
output; the caller can always add that if it's desired, but since a
partitioning constraint is NOT a CHECK constraint I don't actually
think it's useful in most cases.  I also tweaked the regression tests
slightly.

Thanks again.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Hash Functions
Next
From: Pavel Stehule
Date:
Subject: [HACKERS] proposal - using names as primary names of plpgsql functionparameters instead $ based names