Tom,
> I agree however with Andrew's nearby point that this is completely
> unrelated to named parameters to functions/procedures, or to defaults
> for parameters.
I think that was Peter's point, not Andrew's. Andrew agreed with me.
I do think, though, that we should hammer out the parameters, functions,
procedures, etc. "master plan" before anyone gets further coding them, if
people are up for it.
Tom, just to be perfectly clear about why I see Procedures as a way of
resolving parameter ambiguity, my idea is that:
FUNCTIONS will support overloading but will not support named parameter
calling;
PROCEDURES will support named parameter calling but not support overloading.
This resolves the ambiguity. Particularly, I'm concerned about adding any
more code to the evaluation of a function call, out of fear that it will have
a significant performance impact due to increased time to evaluate built-in
functions.
--
Josh Berkus
Aglio Database Solutions
San Francisco
