Re: Proposal: real procedures again (8.4)

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Josh Berkus" <Josh(dot)Berkus(at)sun(dot)com>, "David Fetter" <david(at)fetter(dot)org>
Subject: Re: Proposal: real procedures again (8.4)
Date: 2007-10-27 14:01:15
Message-ID: 162867790710270701o705e2c9cn8e365b94c06b5bac@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2007/10/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-10-27 14:04:20 Re: WAL archiving idle database
Previous Message Gregory Stark 2007-10-27 13:57:01 Re: Proposal: real procedures again (8.4)