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

From Amit Langote
Subject Re: Report error position in partition bound check
Date
Msg-id CA+HiwqF2zo-EdamYCPf4cDi9CzPxMezCCP5CQOYGyfGT57T8qA@mail.gmail.com
Whole thread Raw
In response to Re: Report error position in partition bound check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Report error position in partition bound check  (Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 9, 2020 at 11:04 PM Tom Lane <tgl@sss.pgh.pa.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

pgsql-hackers by date:

Previous
From: Jeremy Morton
Date:
Subject: Support for DATETIMEOFFSET
Next
From: Fujii Masao
Date:
Subject: Re: SyncRepLock acquired exclusively in default configuration