Report error position in partition bound check - Mailing list pgsql-hackers

From Alexandra Wang
Subject Report error position in partition bound check
Date
Msg-id CACiyaSopZoqssfMzgHk6fAkp01cL6vnqBdmTw2C5_KJaFR_aMg@mail.gmail.com
Whole thread Raw
Responses Re: Report error position in partition bound check  (Alexandra Wang <lewang@pivotal.io>)
Re: Report error position in partition bound check  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

I'm playing with partitioned tables and found a minor thing with the
error reporting of bounds checking when create partitions.

In function check_new_partition_bound(), there are three places where
we call ereport() with a parser_errposition(pstate, spec->location)
argument.  However, that pstate is a dummy ParseState made from NULL,
so the error message never reports the position of the error in the
source query line.


I have attached a patch to pass in a ParseState to
check_new_partition_bound() to enable the reporting of the error
position. Below is what the error message looks like before and after
applying the patch.

-- Create parent table
create table foo (a int, b date) partition by range (b);

-- Before:
create table foo_part_1 partition of foo for values from (date '2007-01-01') to (date '2006-01-01');
ERROR:  empty range bound specified for partition "foo_part_1"
DETAIL:  Specified lower bound ('2007-01-01') is greater than or equal to upper bound ('2006-01-01').

-- After:
create table foo_part_1 partition of foo for values from (date '2007-01-01') to (date '2006-01-01');
ERROR:  empty range bound specified for partition "foo_part_1"
LINE 1: ...eate table foo_part_1 partition of foo for values from (date...
                                                             ^
DETAIL:  Specified lower bound ('2007-01-01') is greater than or equal to upper bound ('2006-01-01').

Another option is to not pass the parser_errposition() argument at all
to ereport() in this function, since the query is relatively short and
the error message is already descriptive enough.

Alex and Ashwin
Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Perl modules for testing/viewing/corrupting/repairing your heap files
Next
From: Bruce Momjian
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()