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
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) |