From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Seltenreich <seltenreich(at)gmx(dot)de>, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [sqlsmith] Failed assertion in joinrels.c |
Date: | 2016-08-02 23:16:15 |
Message-ID: | 11796.1470179775@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 2, 2016 at 6:03 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-08-02 23:30:55 | Re: Changed SRF in targetlist handling |
Previous Message | Tom Lane | 2016-08-02 23:02:38 | Re: Changed SRF in targetlist handling |