Re: [sqlsmith] Failed assertion in joinrels.c - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [sqlsmith] Failed assertion in joinrels.c
Date
Msg-id CAA4eK1JvwAeDV5GPxZZrtckh0mMadd0-tL7ZE9bMwwZPwz3aGQ@mail.gmail.com
Whole thread Raw
In response to Re: [sqlsmith] Failed assertion in joinrels.c  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [sqlsmith] Failed assertion in joinrels.c  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Aug 8, 2016 at 4:58 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Aug 3, 2016 at 5:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> I think that's just making life difficult.  If nothing else, sqlsmith
>> hunts around for functions it can call that return internal errors,
>> and if we refuse to fix all of them to return user-facing errors, then
>> it's just crap for the people running sqlsmith to sift through and
>> it's a judgment call whether to fix each particular case.  Even aside
>> from that, I think it's much better to have a clear and unambiguous
>> rule that elog is only for can't-happen things, not
>> we-don't-recommend-it things.
>
>
> I have changed for all these function to report more appropriate error with
> ereport.
>
> I used ERRCODE_WRONG_OBJECT_TYPE error code for reporting such errors.
> I think this is closest error code among all existing error codes, other
> options can be (ERRCODE_WRONG_OBJECT_TYPE).
>

Your other options and the option you choose are same.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [sqlsmith] Failed assertion in joinrels.c
Next
From: Amit Kapila
Date:
Subject: Re: [sqlsmith] Failed assertion in joinrels.c