Re: Report error position in partition bound check

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Report error position in partition bound check
Дата
Msg-id CAG-ACPWrdYjPwYDmeHrZ-QRK9fhLWB43GV7T7dEn_MsVimX=fg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Report error position in partition bound check  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Report error position in partition bound check
Re: Report error position in partition bound check
Список pgsql-hackers


On Fri, 10 Apr 2020 at 14:31, Amit Langote <amitlangote09@gmail.com> wrote:
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.

I looked at this briefly. It looks good, but I will review more in the next CF. Do we have entry there yet? To nit-pick: for a multi-key value the ^ points to the first column and the reader may think that that's the problematci column. Should it instead point to ( ? 

--
Best Wishes,
Ashutosh

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_validatebackup -> pg_verifybackup?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] advanced partition matching algorithm for partition-wise join