[HACKERS] close_ps, NULLs, and DirectFunctionCall

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема [HACKERS] close_ps, NULLs, and DirectFunctionCall
Дата
Msg-id 877ewtm936.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответы Re: [HACKERS] close_ps, NULLs, and DirectFunctionCall  (Emre Hasegeli <emre@hasegeli.com>)
Re: [HACKERS] close_ps, NULLs, and DirectFunctionCall  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
(From IRC discussion with Andreas about some sqlsmith errors)

Commit 278148907a9 changed close_ps in geo_ops.c to return SQL NULL in
the event that a valid result point was not found (rather than crashing
or failing an assert).

But close_ps is called with DirectFunctionCall from other close_*
functions, and indirectly from dist_* functions. So while the specific
case of (point ## lseg) returns a NULL with no error in this case, for
other data types, or for certain dist_* calls, rather than a null result
you get this:

postgres=# select point(1,2) ## '((0,0),(NaN,NaN))'::box;
ERROR:  function 0x9c5de0 returned NULL

postgres=# select point(1,2) <-> '((0,0),(NaN,NaN))'::box;
ERROR:  function 0x9c5de0 returned NULL

This seems ... unhelpful (though it's at least better than crashing) and
inconsistent.

Does this need fixing, and if so how? The most consistent fix would seem
to be to make all the affected functions return NULL, which probably
requires factoring out a bunch of close_*_internal functions and
replacing the DirectFunctionCall usage.

-- 
Andrew (irc:RhodiumToad)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] compress method for spgist - 2
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [HACKERS] why not parallel seq scan for slow functions