>> >> 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 instances of 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 higher overhead with function call is this review complete? any other ideas? Regards Pavel > merlin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
