On Tue, Apr 19, 2011 at 11:22 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Tom Lane's message of mar abr 19 14:22:54 -0300 2011:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> > Excerpts from Robert Haas's message of mar abr 19 13:33:27 -0300 2011:
>> >> Well, I'm all good with that, too, but am not fired up about either
>> >> one to implement it myself. So I think it's going to come down to
>> >> what the person doing the work feels most strongly about.
>>
>> > I'm not at all fired up about stored procedures. The \for pgbench
>> > feature I'm proposing is 2 orders of magnitude less code than that.
>>
>> I think what that really translates to is "I don't want to bother doing
>> the careful design work that Robert talked about". -1 for that approach.
>
> No, actually it doesn't. They're different features. I don't have a
> problem spending time designing it; I do have a problem with designing
> something that I'm not interested in.
>
>> I generally feel that such a feature would be better off done
>> server-side --- after all, there's more clients in the world than psql
>> and pgbench, and not all of them could use a C library even if we had
>> one.
>
> Why do we have pgbench at all in the first place? Surely we could
> rewrite it in plpgsql with proper stored procedures.
By "proper", do you mean "with autonomous transactions"? I don't see
how you could possibly get pgbench functionality into plgsql without
that.
Also, sometimes the libpq stuff is an important part of what you need
to be benchmarking, but I suspect that was part of your rhetorical
point.
Cheers,
Jeff