Re: proposal: plpgsql - iteration over fields of rec or row variable
От | Pavel Stehule |
---|---|
Тема | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Дата | |
Msg-id | AANLkTinRy2gMiB9y53WjtwUeKAhesjWwNyAjTwG2n99d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: plpgsql - iteration over fields of rec or row variable (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: proposal: plpgsql - iteration over fields of rec or row variable
|
Список | pgsql-hackers |
>> >> What is solution in your design? > > nothing specific. My main interest is in the plan management portion > (only because of side interest in search_path which is complete mess > at present). if plpgsql_compile knows that it is trigger function and > which table fired the trigger, you can generate specific hash key, and > take advantage of new/old being well defined inside function > execution. This seems less fiddly than trying to deal with plan > mechanics inside the function. My knowledge stops there -- I don't > have a real good understanding of how plpgsql works internally. If > this idea passes smell test maybe it merits more research. > I still don't understand how it can be used for iteration over record? The basic question is - what tasks we have to solve? a) general constraints over fields b) general initialization over fields c) custom record serialization/deserialization - audits, logs, delta compression, custom formatting (xml, json) Next question - what breaks we have to across? a) using a different types for some fields - invalid plans b) lost of type info c) toast / detoast overhead d) text / binary transformation Possible way: a) transformation to common type + simple - it is one day job - function record_to_array, array_to_record, and fieldnames_to_array- lost of type info, hidden problems with IO cast - int a := 10.0/2.0 is a problem using a plperl, pltcl is same like @a b) FOR OVER or similar loop+ there are not text / binary cast - necessary to introduce a new concept - a multiple instancesof loop's body - longer cache of plans, but it must not be terrible - instance is per distinct field type not per type c) LAMBDA calcul? - maybe Merlin's idea+ there are not text / binary cast+ probably not necessary changes inside plpgsql-it's far to ADA - or do you know any lambda in ADA or PL/SQL?- probably higher overhead with detoast- probably higheroverhead with function call is this review complete? any other ideas? Regards Pavel > merlin >
В списке pgsql-hackers по дате отправления: