>>
>> 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
>