2010/2/24 Josh Berkus :
>
>> val1 is just as ambiguous. I think you got bit by the name collision;
>> the output parameters would start out NULLs and thus lead to the
>> described behavior, in versions before 9.0.
>
> Aha, yeah, that's probably it. Take this example as the reason we had
> to chan
2010/2/24 Josh Berkus :
> Pavel, all:
>
> Apparently if you use one returns table function to call a 2nd returns
> table function, it returns a recordset which consists entirely of nulls.
>
> Here's the test case:
>
> create table srf_data ( id serial, cat int, val text );
> insert into srf_data (
> val1 is just as ambiguous. I think you got bit by the name collision;
> the output parameters would start out NULLs and thus lead to the
> described behavior, in versions before 9.0.
Aha, yeah, that's probably it. Take this example as the reason we had
to change the behavior ...
--Josh Berku
Josh Berkus writes:
> Apparently if you use one returns table function to call a 2nd returns
> table function, it returns a recordset which consists entirely of nulls.
In HEAD that example fails with
psql:josh.sql:30: ERROR: column reference "id1" is ambiguous
LINE 1: select id1, val1 from srf1
Pavel, all:
Apparently if you use one returns table function to call a 2nd returns
table function, it returns a recordset which consists entirely of nulls.
Here's the test case:
create table srf_data ( id serial, cat int, val text );
insert into srf_data ( cat, val ) values
( 1, 'josh' ),
( 1, '
