2011/11/29 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> 2011/11/29 Albe Laurenz <laurenz.a...@wien.gv.at>: >>> There are a lot of small changes to pl/plpgsql/src/pl_exec.c, are they all >>> necessary? For example, why was copy_plpgsql_datum renamed to >>> plpgsql_copy_datum? > >> yes, it's necessary - a implementation is in new file and there is >> necessary call a functions from pg_compile and pg_exec files - >> checking is between compilation and execution - so some functions >> should not be static now. All plpgsql public functions should start >> with plpgsql_ prefix. It is reason for renaming. > > I don't think renaming is necessary. plpgsql is a standalone shared > library and so its symbols don't matter to anybody but itself. > > Possibly a larger question, though, is whether you really need a new > source file. If that results in having to export functions that > otherwise could stay static, maybe it's not the best choice.
This patch was originally in pl_exec.c but this file has a 6170 lines and checking adds 1092 lines - so I moved it to new file It has little bit different semantics, but it is true, so checking hardly depends on routines from pl_exec - routines for variable's management. I have no problem to move it back. I reduces original patch little bit. Some refactoring of pl_exec should be nice - a management of row, record variables and array fields is part that can be shared with SQL/PSM interpret. But I have not idea how it realize. Regards Pavel > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
