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

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: (view raw, whole thread or download thread mbox)
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

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;


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



In response to


pgsql-patches by date

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

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