Re: poll: CHECK TRIGGER?
От | Heikki Linnakangas |
---|---|
Тема | Re: poll: CHECK TRIGGER? |
Дата | |
Msg-id | 4F7C792C.9040108@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: poll: CHECK TRIGGER? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: poll: CHECK TRIGGER?
Re: poll: CHECK TRIGGER? |
Список | pgsql-hackers |
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: