| From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
| Cc: | Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_execute_from_file review |
| Date: | 2010-12-04 00:44:25 |
| Message-ID: | AANLkTi=_4WpF5=wnLw2XoDNL_PkiwN=jZGOgJXZbnaqG@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 3, 2010 at 18:02, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2010-12-04 01:09:24 | Review: Extensions Patch |
| Previous Message | Tom Lane | 2010-12-04 00:38:04 | Re: ERROR: could not identify an equality operator for type box |