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
involved?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
