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.
> But in either case the coding work is going to be dwarfed by the
> design work, if it's done right and not just the-first-hack-that-
> comes-to-mind.
If the feature we're talking about is \for and similar control
structures in pgbench, then no. I'm not really interested in doing
server-side stuff for this kind of thing, mainly because I don't think
it belongs in the server in the first place.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
