Re: [HACKERS] Oddity in error handling of constraint violation inExecConstraints for partitioned tables
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Oddity in error handling of constraint violation inExecConstraints for partitioned tables |
Дата | |
Msg-id | 4408e38a-2198-f94b-c901-3e7156b3dc22@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Oddity in error handling of constraint violation inExecConstraints for partitioned tables (Amit Khandekar <amitdkhan.pg@gmail.com>) |
Ответы |
Re: [HACKERS] Oddity in error handling of constraint violation inExecConstraints for partitioned tables
|
Список | pgsql-hackers |
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 built using the partition table's >>> rowtype, not the root table's. But I think it'd be better to build that >>> using the root table's rowtype, like ExecConstraints, because that would >>> make the column description easier to understand since the parent view(s) >>> (from which WithCheckOptions evaluated there are created) would have been >>> defined on the root table. This seems independent from the above issue, >>> so I created a separate patch, which I'm attaching. What do you think >>> about that? > > + if (map != NULL) > + { > + tuple = do_convert_tuple(tuple, map); > + ExecStoreTuple(tuple, slot, InvalidBuffer, false); > + } > > Above, the tuple descriptor also needs to be set, since the parent and > child partitions can have different column ordering. > > Due to this, the following testcase crashes : > > CREATE TABLE range_parted (a text,b int, c int) partition by range (b); > CREATE VIEW upview AS SELECT * FROM range_parted WHERE (select c > > 120) WITH CHECK OPTION; > create table part_a_1_a_10(b int, c int, a text); > alter table range_parted attach partition part_a_1_a_10 for values > from (1) to (10); > insert into upview values ('a', 2, 100); Good catch. Thanks for creating the patch. There are other places with similar code viz. those in ExecConstraints() that would need fixing. Without the same, the following causes a crash (building on your example): alter table range_parted add constraint check_c check (c > 120); insert into range_parted values ('a', 2, 100); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Attached is the updated version of your patch. A test is also added in insert.sql on lines of the above example. Will add this to the PG 10 open items list. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: