Re: SQL: table function support

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Neil Conway" <neilc(at)samurai(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SQL: table function support
Date: 2008-06-10 09:39:21
Message-ID: 162867790806100239j15f2bd39hf25269d54064971a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

2008/6/10 Neil Conway <neilc(at)samurai(dot)com>:
> On Tue, 2008-06-10 at 06:42 +0200, Pavel Stehule wrote:
>> internally is table functions implemenation identical with SRF.
>
> It's not the internals that I'm concerned about.
>
>> Semantically is far - user's doesn't specify return type (what is from
>> PostgreSQL), but specifies return table, what is more natural. What
>> more - for users is transparent chaotic joice betwen "SETOF RECORD"
>> for multicolumns sets and "SETOF type".
>
> Well, I'd just like to see some thought about how this *entire* feature
> ought to work, rather than just adding new knobs and syntax variants
> incrementally and seemingly at random. Just because it happens to be in
> the standard isn't really a compelling reason to make an overly-complex
> part of the system even more complicated, IMHO...
>
> -Neil
>

This feature has only little sense with plpgsql, but together with
sql's functions allows more readable code. And is significant for
SQL/PSM.

what is more logical and consistent?

create or replace function fx(a integer, out b integer, out c integer)
returns setof record as $$
select a, b
from foo
where a = $1;
$$ language sql;

or

create or replace function fx(a integer)
returns table(b integer, c integer) as $$
select a, b
from foo
where a = $1;
$$ language sql;

Pavel

>
>

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Teodor Sigaev 2008-06-10 11:23:06 Re: GIN improvements
Previous Message Heikki Linnakangas 2008-06-10 09:24:04 Re: \timing on/off