"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Pavel Stehule" <[EMAIL PROTECTED]> writes: >>> Why new calling convention? I would to support byref variables and >>> then I have to carry memory context info ... and maybe some others > >> I think first you have to invent something for the by-ref parameter to refer >> to. > > 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly