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

Reply via email to