Re: proposal: plpgsql - iteration over fields of rec or row variable

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: proposal: plpgsql - iteration over fields of rec or row variable
Дата
Msg-id AANLkTimXR4PcZBZ9sS-QPn6YiCPwM=9osF4wjUJhCWtG@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - iteration over fields of rec or row variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: plpgsql - iteration over fields of rec or row variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Most cases of this feature are for dealing with new/old from trigger
>> function right?  Why not build a complete new plan for each specific
>> trigger that invokes the function, along with some magic values like
>> (TG_FIELDNAMES -> text[]) that could be iterated for the mojo.  Not
>> sure how you get direct type assignment to variable but it could
>> probably be worked out.
>
> if I understand well - it's not too far to my idea - just you create
> instance on function level? It is possible too. As disadvantages I
> see:
> a) you need some special syntax too
> b) there is overhead with multiple function call
> c) you have to manage some space for temporary values

yes.  If you need to deal with plan instance it should be at function
level IMO.  There are other cases for this, search_path for example.
What overhead?

merlin


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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: UNION ALL has higher cost than inheritance