On Tue, Apr 19, 2011 at 11:22 AM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Tom Lane's message of mar abr 19 14:22:54 -0300 2011: >> Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
