2008/7/30 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-07-30 at 08:40 +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2008/7/30 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
>> >> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
>> >> > On Thu, 2008-07-
On Wed, 2008-07-30 at 08:40 +0200, Pavel Stehule wrote:
> Hello
>
> 2008/7/30 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
> >> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
> >> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
> >> >> I've been
Hello
2008/7/30 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
>> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
>> >> I've been working on the TABLE-function patch, and I am coming to the
>> >> con
On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
> >> I've been working on the TABLE-function patch, and I am coming to the
> >> conclusion that it's really a bad idea for plpgsql to not ass
2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
>> I've been working on the TABLE-function patch, and I am coming to the
>> conclusion that it's really a bad idea for plpgsql to not associate
>> variables with output columns --- that is, I think we
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote:
>> The feeling I had about it was that if we were adding
>> PROARGMODE_VARIADIC in 8.4 then there wasn't any very strong argument
>> not to add PROARGMODE_TABLE; any code looking at proargmodes is going
>
On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Why is PROARGMODE_TABLE needed at all ?
>
> Personally I would rather not have it, but Pavel insists it's needed
> for standards compliance in PL/PSM, where output TABLE columns are not
> supposed to
Tom> RETURNS TABLE columns semantically just the same as OUT parameters.
I hope you are not proposing to create another case of crippled OUT
parameters that are quite problematic to use together with inline sql or has
it gotten fixed on the road (we are still using 8.2 on most of our servers).
On
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Why is PROARGMODE_TABLE needed at all ?
Personally I would rather not have it, but Pavel insists it's needed
for standards compliance in PL/PSM, where output TABLE columns are not
supposed to have names visible within the function.
One reason to have it
On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
> I've been working on the TABLE-function patch, and I am coming to the
> conclusion that it's really a bad idea for plpgsql to not associate
> variables with output columns --- that is, I think we should make
> RETURNS TABLE columns semantically j
On 7/18/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 7/18/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> 1. It's ludicrous to argue that "standards compliance" requires the
> >> behavior-as-submitted. plpgsql is not specified by the SQL standard.
>
>
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 7/18/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> 1. It's ludicrous to argue that "standards compliance" requires the
>> behavior-as-submitted. plpgsql is not specified by the SQL standard.
> Yes, but it would be a good feature addition to plpgsql.
> C
On 7/18/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> I've been working on the TABLE-function patch, and I am coming to the
> conclusion that it's really a bad idea for plpgsql to not associate
> variables with output columns --- that is, I think we should make
> RETURNS TABLE columns semantically j
2008/7/18 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Maybe we can use some well defined implicit record, maybe NEW (or
>> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
>
> That sounds like exactly the sort of kluge-solution that I didn't
> wan
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Maybe we can use some well defined implicit record, maybe NEW (or
> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
That sounds like exactly the sort of kluge-solution that I didn't
want to get involved with ...
Anyway, the core feat
Hello
The core of problems is in standard that doesn't know RETURN NEXT
statement and knows only RETURN TABLE statement - so PL/pgPSM or SQL
doesn't have problem. I am not sure about PL/pgSQL, but I thing so
using TABLE attribs as OUT variables is maybe too simple solution -
there isn't any progre
I've been working on the TABLE-function patch, and I am coming to the
conclusion that it's really a bad idea for plpgsql to not associate
variables with output columns --- that is, I think we should make
RETURNS TABLE columns semantically just the same as OUT parameters.
Here are some reasons:
1.
17 matches
Mail list logo
