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

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 (view raw or flat)
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

pgsql-hackers by date

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

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