Re: [sqlsmith] Failed assertion in joinrels.c
От | Amit Kapila |
---|---|
Тема | Re: [sqlsmith] Failed assertion in joinrels.c |
Дата | |
Msg-id | CAA4eK1JvwAeDV5GPxZZrtckh0mMadd0-tL7ZE9bMwwZPwz3aGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Failed assertion in joinrels.c (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [sqlsmith] Failed assertion in joinrels.c
|
Список | 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 по дате отправления: