Re: why can't plpgsql return a row-expression?
От | Alvaro Herrera |
---|---|
Тема | Re: why can't plpgsql return a row-expression? |
Дата | |
Msg-id | 20121127205541.GO4227@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: why can't plpgsql return a row-expression? (Asif Rehman <asifr.rehman@gmail.com>) |
Ответы |
Re: why can't plpgsql return a row-expression?
|
Список | pgsql-hackers |
Asif Rehman escribió: > Hi, > > I have tried to solve this issue. Please see the attached patch. > > With this patch, any expression is allowed in the return statement. For any > invalid expression an error is generated without doing any special handling. > When a row expression is used in the return statement then the resultant > tuple will have rowtype in a single column that needed to be extracted. > Hence I have handled that case in exec_stmt_return(). > > any comments/suggestions? Hmm. We're running an I/O cast during do_tup_convert() now, and look up the required functions for each tuple. I think if we're going to support this operation at that level, we need to look up the necessary functions at convert_tuples_by_foo level, and then apply unconditionally if they've been set up. Also, what are the implicancies for existing users of tupconvert? Do we want to apply casting during ANALYZE for example? AFAICS the patch shouldn't break any case that works today, but I don't see that there has been any analysis of this. (I looked at the patch posted in the thread started by Pavel elsewhere. I'm replying to both emails in the interest of keeping things properly linked.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: