Re: TABLE-function patch vs plpgsql - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: TABLE-function patch vs plpgsql
Date
Msg-id 1217348847.8386.4.camel@huvostro
Whole thread Raw
In response to TABLE-function patch vs plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TABLE-function patch vs plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: TABLE-function patch vs plpgsql  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-hackers
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 ?

> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Python 2.5 vs the buildfarm
Next
From: Tom Lane
Date:
Subject: Re: TABLE-function patch vs plpgsql