proposal: table functions and plpgsql
От | Pavel Stehule |
---|---|
Тема | proposal: table functions and plpgsql |
Дата | |
Msg-id | 162867790805210912u2b33abbfqae76a7c4b8a4bf17@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: proposal: table functions and plpgsql
Re: proposal: table functions and plpgsql |
Список | pgsql-hackers |
Hello I am returning back to my patch and older proposal http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php . Some work did Neil Conway http://archives.postgresql.org/pgsql-hackers/2007-07/msg00501.php and he commited half of this patch - RETURN QUERY part. Problematic part of my patch is implementation. Tom Lane proposal implenation RETURNS TABLE only as syntactic sugar for RETURNS SETOF RECORD. This is not comaptible with potential implementation, because it adds some default variables. My solution was special argmode, so I was able don't create default variables for output. My solution wasn't best too. It was ugly for current plpgsql where is often used RETURN NEXT statement (PSM doesn't know similar statement). I unlike default variables - it simply way to variables and column names collision. I propose following syntax for plpgsql: CREATE OR REPLACE FUNCTION foo(m integer) RETURNS TABLE (a integer, b integer) AS $$ DECLARE r foo; -- same name as function, this type has local visibility BEGIN FOR i IN 1..m LOOP r.a := i; r.b := i + 1; RETURN NEXT r; END LOOP; RETURN; END; $$ LANGUAGE plpgsql; In my proposal I don't create any default variables. Result type is only virtual - I don't need write it to system directory. I thing it's better than using some specific predeclared type as RESULTTYPE OR RESULTSET. What do you thing about? Regards Pavel Stehule
В списке pgsql-hackers по дате отправления: