Re: Report error position in partition bound check

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexandra Wang <lewang(at)pivotal(dot)io>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com>
Subject: Re: Report error position in partition bound check
Date: 2020-04-10 09:01:37
Message-ID: CA+HiwqF2zo-EdamYCPf4cDi9CzPxMezCCP5CQOYGyfGT57T8qA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 9, 2020 at 11:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> While I'm quite on board with providing useful error cursors,
> the example cases in this patch don't seem all that useful:
>
> -- trying to create range partition with empty range
> CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (1) TO (0);
> ERROR: empty range bound specified for partition "fail_part"
> +LINE 1: ...E fail_part PARTITION OF range_parted2 FOR VALUES FROM (1) T...
> + ^
> DETAIL: Specified lower bound (1) is greater than or equal to upper bound (0).
>
> As best I can tell from these examples, the cursor will always
> point at the FROM keyword, making it pretty unhelpful. It seems
> like in addition to getting the query string passed down, you
> need to do some work on the code that's actually reporting the
> error position. I'd expect at a minimum that the pointer allows
> identifying which column of a multi-column partition key is
> giving trouble. The phrasing of this particular message, for
> example, suggests that it ought to point at the "1" expression.

I agree with that. Tried that in the attached 0002, although trying
to get the cursor to point to exactly the offending column seems a bit
tough for partition overlap errors. The patch does allow to single
out which one of the lower and upper bounds is causing the overlap
with an existing partition, which is better than now and seems helpful
enough.

Also, updated Alexandra's patch to incorporate Ashutosh's comment such
that we get the same output with ATTACH PARTITION commands too.

--

Amit Langote
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
v3-0001-Report-error-position-in-partition-bound-check.patch application/octet-stream 16.1 KB
v1-0002-Improve-check_new_partition_bound-error-position-.patch application/octet-stream 13.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-04-10 09:57:12 Re: SyncRepLock acquired exclusively in default configuration
Previous Message Jeremy Morton 2020-04-10 08:34:51 Support for DATETIMEOFFSET