Gavin, > My real question, however, is do we want default values at all. Josh has > been fairly keen on them but I haven't seen much outright support for the > idea other than Joe and Joshua (perhaps a few others) putting the argument > that anything which eases the burden of migration from SQL Server is > (potentially) a good thing.
Let me advance the reason *I* want them. I do a lot of applications with extensive, procedure-driven business logic. One of the things I constantly run up against is when a widely used procedure needs a new parameter. With functions as they stand now, I have to create a "shell" function that encompasses the new parameter -- which starts to get hard to track when it's happened 3 or 4 times. (woe is the lot of those with spec drift) It also allows code neatness by not forcing you to constantly look up the order of parameters in the function catalog. For example, this: sf_cases ( user = 124223, session = 114643343, casename = 'VIKTOR', client = 'KELLEY', managedby = NULL, status = 1, fuzzysearch = TRUE, filedafter = NULL, format = 'long', page = 1, resultsper = 15 ); Is easier to both read an maintain than: sf_cases ( 124223, 114643343, 'VIKTOR', 'KELLEY', NULL, 1, TRUE, NULL, 'long', 1, 15); Of course, this is as true of functions as it will be of procedures. So half the functionality that I'm angling for to support with calling named params could be accomplished within the context of overloading just by extending the named param patch in 8.0 to cover calling functions/SPs in the format above. Therefore: the arguments you raise about the difficulty of implementing a seperate catalog are strong ones, and you are probably correct in the tradeoff being a bad one. And, not that I think about it, I have a way to support DEFAULT params within the context of overloading. Let me muse it over and I'll get back to you. > I think we can distinguish between functions and procedures based on > context -- there is one case which will affect people, however. So, do we still need to distinguish if we're not supporting default params? > iii) Support functions and procedures through SQL > > Instead of adding EXECUTE FUNCTION, we could have: > > FOR EACH { ROW | STATEMENT } { SELECT <funcname> | CALL <procedure> } > > This gives us the option, I believe, of moving to full SQL comformance in > the future as well as giving people (and pg_dump) and upgrade path. I like this because of the SQL conformance, completely aside from issues of determinism. > Is foo() a function or procedure? I think it is reasonable to say that > only procedures can be called in this fashion, and that function need be > invoked with PERFORM or in a query, as we have in 7.4, etc. Frankly, I agree here. For one thing, any Function being called in that fashion is effectively being treated as a procedure -- the value it returns is being thrown away. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster