On 10/27/07, Gregory Stark <stark@enterprisedb.com> wrote:
> > Most of that sounded to me like a proposal to re-invent ecpg. If there
> > were such a large demand for doing things that way, there would be many
> > more users of ecpg than bare libpq. AFAICT, though, *very* few people
> > use ecpg.
>
> ecpg is a client-side thing though, isn't it? So, for example if you are
> writing some large batch job for which you want to process many records,
> occasionally updating some of them you would end up having to download all the
> data to the client.
>
> I think what people want is something like plpgsql, ie, it runs on the server
> and can access the data without having to marshal and unmarshal it over the
> wire to a client. They just want to be able to use plpgsql outside of a
> transaction so they can start and commit transactions within the execution
> context of the PL execution environment.
>
> And they want to program it using a procedural style, with mutable per-session
> variables storing state. It's not clear to me whether those variables should
> be transactional but I don't think most people expect them to be. They expect
> cheap per-session non-transactional variables which have no additional
> overhead over plpgsql variables but can be referenced easily from any SQL so
> if the variable's value is change the meaning of their SQL magically changes.
IMHO, you are right on the money with all your points. The major
point of procedures is manual transaction management...this would
allow folding into the database many things that are now only possible
though the protocol.
Mutable session variables would be nice, but I'll take a plpgsql
langauge (or psm) with or without them, so long as transactions are
manual. It's possible to emulate variables using scalar functions
with the desired volatility currently (but you still have to be
careful with transactions).
merlin