Re: plpgsql TABLE patch

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Neil Conway" <neilc(at)samurai(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
Subject: Re: plpgsql TABLE patch
Date: 2007-09-26 06:03:33
Message-ID: 162867790709252303p72773d3al171f735d8a32a8f4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Sorry, my day job is currently taking up all my spare cycles :( So I
> don't think I'll get a chance to wrap this up for 8.3.
>
> My recollection is that the patch was okay as far as it went, but I'm
> hesitant to add yet another alternative to the already complex set of
> choices for returning composite types and sets from functions. If we
> just make TABLE() syntax sugar for the existing OUT function stuff we
> would avoid at least some of that complexity, but Pavel still prefers a
> distinct proargmode, last I heard.
>

Method isn't important for me - important is semantic. If you
implement TABLE like shortcut to current OUT variables, you have to
have some implicit variables inside function and it is in
contradiction with standard. That's all. So TABLE functions without
SQL/PSM isn't tragedy :), but if we implement SQL/PSM cleanly then we
need table's functions. It's only one way for output set, which is
specified by standard.

Regards
Pavel Stehule

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-09-26 08:26:30 Re: Background LRU Writer/free list
Previous Message Tom Raney 2007-09-26 05:43:18 Re: Hash index todo list item