Re: why can't plpgsql return a row-expression?

Поиск
Список
Период
Сортировка
От Asif Rehman
Тема Re: why can't plpgsql return a row-expression?
Дата
Msg-id CADM=Jeg2nSb-NCDjg98LNYdKPygxR2EZWMrvrQdjYVSizKHsAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: why can't plpgsql return a row-expression?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: why can't plpgsql return a row-expression?
Список pgsql-hackers
Дерево обсуждения
Hi,

Thanks for the review. Please see the updated patch.

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.
Done. TupleConversionMap struct should keep the array of functions oid's that 
needs to be applied. Though only for those cases where both attribute type id's
do not match. This way no unnecessary casting will happen. 


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 believe this part of the code should not impact existing users of tupconvert.  
As this part of code is relaxing a restriction upon which an error would have been
generated. Though it could have a little impact on performance but should be only for 
cases where attribute type id's are different and are implicitly cast able.

Besides existing users involve tupconvert in case of inheritance. And in that case 
an exact match is expected.

Regards,
--Asif
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: visibilitymap_count() at the end of vacuum
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add mode where contrib installcheck runs each module in a separa