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
