Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On Mon, Jul 24, 2017 at 6:21 AM, Amit Langote wrote: > Yes, we need that there too. > > Done that in the attached v3 (including the test where > ExecPartitionCheck() would have crashed without the patch). Committed. Thanks to all of you. -- Robert Haas

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On 2017/07/24 17:30, Etsuro Fujita wrote: > On 2017/07/24 16:16, Amit Khandekar wrote: >> On 24 July 2017 at 12:11, Amit Langote >> wrote: >>> Attached is the updated version of your patch. > > Good catch, Amit K. and Amit L.! > >> Now that this is done, any

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On 2017/07/24 16:16, Amit Khandekar wrote: On 24 July 2017 at 12:11, Amit Langote wrote: Attached is the updated version of your patch. Good catch, Amit K. and Amit L.! Now that this is done, any particular reason it is not done in ExecPartitionCheck() ? I

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On 24 July 2017 at 12:11, Amit Langote wrote: > Hi Amit, > > On 2017/07/24 14:09, Amit Khandekar wrote: On 2017/07/10 14:15, Etsuro Fujita wrote: Another thing I noticed is the error handling in ExecWithCheckOptions; it doesn't take any care for

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

Hi Amit, On 2017/07/24 14:09, Amit Khandekar wrote: >>> On 2017/07/10 14:15, Etsuro Fujita wrote: >>> Another thing I noticed is the error handling in ExecWithCheckOptions; it >>> doesn't take any care for partition tables, so the column description in >>> the error message for WCO_VIEW_CHECK is

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

>> On 2017/07/10 14:15, Etsuro Fujita wrote: >> Another thing I noticed is the error handling in ExecWithCheckOptions; it >> doesn't take any care for partition tables, so the column description in >> the error message for WCO_VIEW_CHECK is built using the partition table's >> rowtype, not the

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

Fujita-san, On 2017/07/10 14:15, Etsuro Fujita wrote: > On 2017/07/07 18:47, Amit Langote wrote: >> On 2017/07/06 16:06, Etsuro Fujita wrote: >>> I think this should be fixed. Attached is a patch for that. > >> How about setting ri_RangeTableIndex of the partition ResultRelInfo >> correctly in

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On 2017/07/07 18:47, Amit Langote wrote: On 2017/07/06 16:06, Etsuro Fujita wrote: I think this should be fixed. Attached is a patch for that. Looking up the ResultRelInfo using the proposed method in ExecFindResultRelInfo() can be unreliable sometimes, that is, the method of using the root

Re: [HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

Fujita-san, On 2017/07/06 16:06, Etsuro Fujita wrote: > Here is an example: > > postgres=# create table col_desc (a int, b int) partition by list (a); > postgres=# create table col_desc_1 partition of col_desc for values in (1); > postgres=# alter table col_desc_1 add check (b > 0); > postgres=#

[HACKERS] Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

Here is an example: postgres=# create table col_desc (a int, b int) partition by list (a); postgres=# create table col_desc_1 partition of col_desc for values in (1); postgres=# alter table col_desc_1 add check (b > 0); postgres=# create role col_desc_user; postgres=# grant insert on col_desc to