Function argument names
От | Dennis Bjorklund |
---|---|
Тема | Function argument names |
Дата | |
Msg-id | Pine.LNX.4.44.0312140817180.32102-101000@zigo.dhs.org обсуждение исходный текст |
Ответы |
Re: Function argument names
|
Список | pgsql-patches |
Hi I've implemented function argument names, which lets you write functions like this: CREATE FUNCTION bar (a int, b int) RETURNS int AS ' BEGIN RETURN a + b; END; ' LANGUAGE 'plpgsql'; It works by storing the variable names in a text[] field in pg_proc and then the language handler can access these if it wants to (and I've implemented that for pl/pgsql). The patch is fairly big since it has to touch a lot of places: * The parser * The syntax tree (with help functions) * The system tables pg_proc and pg_attribute * The language pl/pgsql * pg_dump Other languages then pl/pgsql should also work to extend, but I've not looked at that. The langage sql I've planned to look at, but since that language is not as separate as the others I did not want to do it yet. The patch is big as it is. What's missing are changes to the documentation. I've added an entry for the column in pg_proc, but that is all. The syntax above is from sql99 (I think, I've only looked at sql2003). Sql99 also lets you define the names of OLD and NEW for triggers, which would be easy now. For the changes in pl_comp.c it feels like I'm breaking the abstraction when I pull out the argument names from the array. It uses the fact that I know how text[] arrays are stored. I found no better way to do it. I'd be happy if I could pull out the strings without knowing anything of how these are stored. The changes to the system tables was harder then I thought it was going to be. The code in pg contains a lot of hard coded assumptions of what these looks like. For example, prosrc has to be the first vararg element in pg_proc, which I learned the hard way.. -- /Dennis
Вложения
В списке pgsql-patches по дате отправления: