On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
