Re: [sqlsmith] Failed assertion in joinrels.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [sqlsmith] Failed assertion in joinrels.c
Дата
Msg-id 11796.1470179775@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [sqlsmith] Failed assertion in joinrels.c  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [sqlsmith] Failed assertion in joinrels.c  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 2, 2016 at 6:03 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>> There are many more such exposed functions, which can throw cache lookup
>> failure error if we pass wrong value.
>> 
>> i.e.
>> record_in
>> domain_in
>> fmgr_c_validator
>> plpgsql_validator
>> pg_procedure_is_visible
>> 
>> Are we planning to change these also..

> I think if they are SQL-callable functions that users can invoke from
> a SQL prompt, they shouldn't throw "cache lookup failed" errors or,
> for that matter, any other error that is reported with elog().

FWIW, I would restrict that to "functions that users are *intended* to
call from a SQL prompt".  If you are fooling around calling internal
functions with garbage input, you should not be surprised to get an
internal error back.  So of the above list, only pg_procedure_is_visible
seems particularly worth changing to me.  And for it, returning NULL
(ie, "unknown") seems reasonable enough.

Actually, it looks to me like we already fixed that for the built-in
is_visible functions:

# select pg_function_is_visible(0) is null;?column? 
----------t
(1 row)

There's no such animal as pg_procedure_is_visible.  I suspect that's an
EDB-ism that hasn't caught up with commit 66bb74dbe8206a35.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Changed SRF in targetlist handling
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Changed SRF in targetlist handling