Skip site navigation (1) Skip section navigation (2)

Re: TABLE-function patch vs plpgsql

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Hannu Krosing" <hannu(at)krosing(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TABLE-function patch vs plpgsql
Date: 2008-07-30 05:29:34
Message-ID: 162867790807292229xe45ddfcja1f5d41e904de3c4@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2008/7/29 Hannu Krosing <hannu(at)krosing(dot)net>:
> On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
>> I've been working on the TABLE-function patch, and I am coming to the
>> conclusion that it's really a bad idea for plpgsql to not associate
>> variables with output columns --- that is, I think we should make
>> RETURNS TABLE columns semantically just the same as OUT parameters.
>
> I just looked at recent cahnges in pl/python, and found out that RETURNS
> TABLE is _NOT_ semantically just the same as OUT parameters, at least at
> API level.
>
> Why can't it be ?
>
> Why is PROARGMODE_TABLE needed at all ?

because I need to separate classic OUT args from table args. TABLE
function has more clean syntax, then our SRF functions, and it isn't
related only to SQL/PSM. It works nice together with SQL language.
Actually TABLE   variables are exactly same as OUT variables (in
plpgsq), that is possible, but I am not sure, if it's best too.

I have prototype where is possible declare variables derivated from
function return type
create function foo(..) returns table(x int, y int) as $$
declare result foo%rowtype; resx foo.x%type; ....

all this has to minimalist risk of variables and sql object name collisions.

Regards
Pavel Stehule

>
>> 4. It's a whole lot easier to explain things if we can just say that
>> OUT parameters and TABLE parameters work alike.  This is especially
>> true when they actually *are* alike for all the other available PLs.
>
> It would be nice, if they were the same at API level as well.
>
> --------------------
> Hannu
>
>

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2008-07-30 06:19:56
Subject: Re: TABLE-function patch vs plpgsql
Previous:From: Robert LorDate: 2008-07-30 04:34:54
Subject: Re: Review: DTrace probes (merged version) ver_03

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group