Re: Proposal: real procedures again (8.4)

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> 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