Re: Proposal: real procedures again (8.4) - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Proposal: real procedures again (8.4)
Date
Msg-id 162867790710270701o705e2c9cn8e365b94c06b5bac@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: real procedures again (8.4)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: real procedures again (8.4)
List pgsql-hackers
2007/10/27, Tom Lane <tgl@sss.pgh.pa.us>:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Pavel Stehule" <pavel.stehule@gmail.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.
>

With procedures we can be in conformance with ANSI standard and others
databases. New SQL2006 standards contains lot of SQL/PSM code and will
be usefull, if we can port this code without changes.

New calling convention can simplify life. It can support more than one
output value. Actual solution is practical, but is too complicated for
C code, because I have to do create tuple when I would to return two
ints ...

Pavel


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Proposal: real procedures again (8.4)
Next
From: Camilo Porto
Date:
Subject: Re: URGENT HELP about 'duration' stats