Thread: Function argument names

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

Dennis Bjorklund <db@zigo.dhs.org> writes:
> I've implemented function argument names,

I have reviewed and applied this patch, with some editorialization.

> 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.

I am not real sure what support for this should look like in SQL
functions.  From the point of view of a SQL command inside a function,
it seems very close to a global SQL variable, which is a notion that
we've always shied away from.  The PL languages are more comfortable
with such things, and should probably get fixed first.

Also, wouldn't it be a good idea for psql's \df or \df+ commands to
show the argument names?

> What's missing are changes to the documentation.

Yup.  Please supply.  Note that I fixed the grammar to allow param names
to appear in *any* function parameter list, not only CREATE FUNCTION.
For instance "DROP FUNCTION x(p int)".  (I believe that the pg_dump
patch requires this, in fact.)

> 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.

So you were.  I didn't do it that way.

> 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..

That's a bug; fixed.  It is true that changing the bootstrapped tables
like pg_class and pg_proc requires changes in more than one place,
mostly undocumented places.  But you did it, and lived to tell the tale ;-).
Be glad.  Do you feel like contributing some documentation about what's
involved?

            regards, tom lane