2011/11/29 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/11/29 Albe Laurenz <laurenz.albe@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
>