Re: review: CHECK FUNCTION statement

2011/11/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2011/11/29 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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
>