| From: | Hannu Krosing <hannu(at)krosing(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: TABLE-function patch vs plpgsql |
| Date: | 2008-07-29 16:27:27 |
| Message-ID: | 1217348847.8386.4.camel@huvostro |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-07-29 16:46:48 | Re: TABLE-function patch vs plpgsql |
| Previous Message | Tom Lane | 2008-07-29 16:24:59 | Re: Python 2.5 vs the buildfarm |