Re: Report error position in partition bound check

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexandra Wang <lewang(at)pivotal(dot)io>
Cc: 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-09 14:03:55
Message-ID: 28553.1586441035@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2020-04-09 14:04:01 Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Previous Message Fujii Masao 2020-04-09 14:02:21 Re: Planning counters in pg_stat_statements (using pgss_store)