Dennis Bjorklund <[EMAIL PROTECTED]> 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

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to