2012/4/4 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> On 04.04.2012 19:32, Tom Lane wrote:
>>
>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>>>
>>> I don't think I'm getting my point across by explaining, so here's a
>>> modified version of the patch that does what I was trying to say.
>>
>>
>> Minor side point: some of the diff noise in this patch comes from
>> s/copy_plpgsql_datum/plpgsql_copy_plpgsql_datum/, which seems entirely
>> useless. The name already contains "plpgsql", and even if it didn't,
>> there is no particular reason for plpgsql to worry about polluting
>> global symbol namespace. Nothing else resolves against its symbols
>> anyway, at least not on any platform we claim to support. I would
>> therefore also argue against the other renamings like
>> s/exec_move_row/plpgsql_exec_move_row/.
>
>
> Agreed. Looking closer, I'm not sure we even need to expose exec_move_row()
> to pl_check.c. It's only used to initialize row-type function arguments to
> NULL. But variables that are not explicitly initialized are NULL anyway, and
> the checker shouldn't use the values stored in variables for anything, so I
> believe that initialization in function_check() can be replaced with
> something much simpler or removed altogether.
+1
Pavel
>
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
