Re: BUG #15668: Server crash in transformPartitionRangeBounds - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #15668: Server crash in transformPartitionRangeBounds
Date
Msg-id 20190320091727.GE26601@paquier.xyz
Whole thread Raw
In response to Re: BUG #15668: Server crash in transformPartitionRangeBounds  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: BUG #15668: Server crash in transformPartitionRangeBounds  (Michael Paquier <michael@paquier.xyz>)
Re: BUG #15668: Server crash in transformPartitionRangeBounds  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Wed, Mar 20, 2019 at 06:07:23PM +0900, Amit Langote wrote:
> because we can notice the aggregate before we look into its arguments.
> Maybe, we should move the error-checking switch to a point before checking
> the arguments?  That looks slightly more drastic change to make though.

Yeah, I think that it would be more invasive because the parsing logic
looks at the column references first.  This way of doing things is
also something which is logic in its own way as the most internal
portions of an expression get checked first, so I quite like that way
of doing things.  And that's just consistent with the point of view of
the parsing check order.

> We may want to fix the crash first.  It might be better to hear other
> opinions before doing something about the error messages.

The thing is that in order to keep the tests for the crash, we finish
with the inintuitive RTE-related errors, so it is also inconsistent to
not group things..
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Amit Langote
Date:
Subject: Re: BUG #15668: Server crash in transformPartitionRangeBounds
Next
From: Tom Lane
Date:
Subject: Re: BUG #15703: Segfault in cancelled CALL-Statements