Re: Proposal: TABLE functions

From: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: TABLE functions
Date: 2007-02-09 17:22:09
Message-ID: BAY114-F385390560C897143BEBF04F99C0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >> I thought you said this was just syntactic sugar for capabilities we
> >> already had?
>
> > My mistake. I am sorry. I have to store somewhere flag. One bit, which
> > signalise "don't use OUT arguments as function's parameters".
>
>Huh? What exactly is the meaning of the arguments then?
>
>It sounds to me like this might be better thought of as a new
>proargmode value, but I'm quite unsure what you're talking about ...
>

My basic idea was:

CREATE FUNCTION aaa(IN a1, OUT a, OUT b)
RETURNS SETOF RECORD AS $$
..

is similar
CREATE FUNCTION aaa(IN a1)
RETURNS SETOF RECORD AS $$

from executor perspective there isn't any difference. But PL languages have
to create only IN variables. It's protection before identifier's name
colision. With special flag I don't need any changes in executor. And small
change in PL compile rutines. Special proargmode can be solution too. I
don't need new column in pg_proc, but have to modify executor and need more
changes in output rutines in PL.

I'll go on the way to spec. proargmode. It's good idea.

Thank You
Pavel Stehule

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-02-09 17:29:12 Re: HOT for PostgreSQL 8.3
Previous Message Simon Riggs 2007-02-09 17:08:52 Re: HOT for PostgreSQL 8.3