Re: BUG #15668: Server crash in transformPartitionRangeBounds

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: exclusion(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: BUG #15668: Server crash in transformPartitionRangeBounds
Date: 2019-03-06 07:00:42
Message-ID: 6ed2c24c-2f73-fa1c-0ed1-ed3597f13d0d@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi,

On 2019/03/06 15:48, Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 11:04:17PM +0900, Amit Langote wrote:
>> Maybe we should error out as follows in
>> transformPartitionRangeBounds(), although that means we'll get
>> different error message than when using list partitioning syntax:
>
> Hm. I don't think that this is a good idea as you could lose some
> information for the expression transformation handling, and the error
> handling becomes inconsistent depending on the partition bound
> strategy. It seems to me that if we cannot extract any special value
> from the ColumnRef expression generated, then we ought to let
> transformPartitionBoundValue() and particularly transformExprRecurse()
> do the analysis work and complain if needed:
> =# CREATE TABLE rp_part PARTITION OF range_parted FOR VALUES FROM
> (unknown.unknown) TO (1);
> ERROR: 42P01: missing FROM-clause entry for table "unknown"
> LINE 1: ...p_part PARTITION OF range_parted FOR VALUES FROM
> (unknown.un...
> =# CREATE TABLE rp_part PARTITION OF range_parted FOR VALUES FROM
> (a.a.a.a.a.a.a.a.a.a.a.a) TO (1);
> ERROR: 42601: improper qualified name (too many dotted names):
> a.a.a.a.a.a.a.a.a.a.a.a
> LINE 1: ...p_part PARTITION OF range_parted FOR VALUES FROM
> (a.a.a.a.a....
>
> What about something like the attached instead? Minus the test
> cases which should go to create_table.sql of course.

Thanks for looking at this. Your patch seems better, because it allows us
to keep the error message consistent with the message one would get with
list-partitioned syntax.

Thanks,
Amit

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-03-06 08:27:30 Re: BUG #15668: Server crash in transformPartitionRangeBounds
Previous Message Michael Paquier 2019-03-06 06:48:25 Re: BUG #15668: Server crash in transformPartitionRangeBounds

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-03-06 07:07:21 Re: Pluggable Storage - Andres's take
Previous Message Michael Paquier 2019-03-06 06:48:25 Re: BUG #15668: Server crash in transformPartitionRangeBounds