Re: plpgsql TABLE patch - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql TABLE patch
Date
Msg-id 162867790709252303p72773d3al171f735d8a32a8f4@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql TABLE patch  (Neil Conway <neilc@samurai.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Raney
Date:
Subject: Re: Hash index todo list item
Next
From: Bruce Momjian
Date:
Subject: Re: Background LRU Writer/free list