Re: pg_execute_from_file review - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_execute_from_file review
Date
Msg-id 2335.1291590115@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_execute_from_file review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: pg_execute_from_file review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Re: pg_execute_from_file review  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_execute_from_file review  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
> On Fri, Dec 3, 2010 at 18:02, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> 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.

Why is there a variadic replace() in this patch at all?  It seems just
about entirely unrelated to the stated purpose of the patch, as well
as being of dubious usefulness.  When would it be superior to
replace(replace(orig, from1, to1), from2, to2), ...

The implementation doesn't appear to offer any material speed
improvement over nested calls of that sort, and I'm finding it hard to
visualize when it would be more useful than nested calls.  The
documentation is entirely inadequate as well.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: CommitFest 2010-11: Status report at 2/3 of scheduled time
Next
From: Greg Smith
Date:
Subject: Re: Spread checkpoint sync