Re: pg_execute_from_file review

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: pg_execute_from_file review
Дата
Msg-id AANLkTi=_4WpF5=wnLw2XoDNL_PkiwN=jZGOgJXZbnaqG@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_execute_from_file review  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: pg_execute_from_file review  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: pg_execute_from_file review  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Dec 3, 2010 at 18:02, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>    Schema   |  Name   | Result data type | Argument data types |  Type
> ------------+---------+------------------+---------------------+--------
>  pg_catalog | replace | text             | text, VARIADIC text | normal
>  pg_catalog | replace | text             | text, text, text    | normal
>
> My understanding is that the variadic form shadows the other one in a
> way that it's now impossible to call it from SQL level. That's the
> reason why I did the (text, text, text, VARIADIC text) version before,
> but is it true?

The VARIADIC version doesn't hide the 3-args version. I tested the
behavior by printf-debug. The planner seems to think the non VARIADIC
version is the best-matched one when 3 arguments are passed.

> Also, is it worthwhile to keep the non VARIADIC
> version exposed at SQL level?

Yes, because the non VARIADIC version is much faster than the
VARIADIC one. Of course we could optimize the performance of
replace_text_variadic(), but I think VARIADIC argument itself
is slow because it puts arguments into an array shape.

--
Itagaki Takahiro


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: could not identify an equality operator for type box
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Review: Extensions Patch