On 24/01/11 05:42, Hitoshi Harada wrote:
> 2011/1/23 Jan Urbański <wulczer@wulczer.org>:
>> On 22/01/11 11:15, Hitoshi Harada wrote:
> I tested the new incremental patch and the previous example works
> fine. I don't know if this can be handled properly but another example
> is:
>
> regression=# create function func1(t text) returns record as $$ return
> {'name':t, 'value':0}; $$ language plpythonu ;
> CREATE FUNCTION
> regression=# select * from func1('jan') as (name text, value bigint);
> name | value
> ------+-------
> jan | 0
> (1 row)
>
> regression=# select * from func1('jan') as (value text, name bigint);
> value | name
> -------+------
> jan | 0
> (1 row)
>
> where value and name don't point to the correct data. Your
> data-type-check logic might not be enough.
I have to admit that I don't 100% understand what's happening when you
have a function that returns RECORD and has no OUT parameters, but I did
a quick check with PL/pgSQL and it behaves the same:
create or replace function rec(t text) returns record as $$
declare
r record;
begin
select t as name, 0 as value into r;
return r;
end;
$$ language plpgsql;
pl_regression=# select * from rec('jan') as (value text, name integer);
value | name
-------+------
jan | 0
(1 row)
pl_regression=# select * from rec('jan') as (name text, value integer);
name | value
------+-------
jan | 0
(1 row)
So PL/pgSQL seems to work positionally, whereas PL/Python uses the
variable names when fetching them from the mapping Python returned. All
in all, it works the same as in other PLs, so at least it's consistent.
I'm also attaching an updated version that should apply on top of my
github refactor branch (or incrementally over the new set of refactor
patches that I will post shortly to the refactor thread).
Cheers,
Jan
