On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus <josh@agliodbs.com> wrote:
> Would a patch that changes that have any chance of being accepted? Or is > the gain (not having to repeat the DEFAULT clause, and being able to > maintain it at one place instead of many) considered too small compared > to the risk of breaking existing code?
I don't think there's a lot of risk of code breakage; few people use domains, fewer use them with defaults, and you might be the only one using them as variable types. And there are going to be more substantial backwards compat issues with the lexer changes anyway. As long as we remember to flag the compatibility issue in the release notes, I don't see it as a problem.
However, there are some other issues to be resolved:
(1) what should be the interaction of DEFAULT parameters and domains with defaults?
The function's DEFAULT parameter should take precedence over the default of the domain.
(2) this change, while very useful, does change what had been a simple rule ("All variables are NULL unless specifically set otherwise") into a conditional one ("All variables are NULL unless set otherwise OR unless they are declared as domain types with defaults"). Do people feel that the new behavior would be sufficiently intuitive to avoid user confusion?
I see this as a straight-forward extension to what we've had till now; and I bet some users would've definitely expected them to work this way in the past..
(3) Last I checked, there were still several places in which domains did not behave consistently in stored procedures. I think that Elein had some unfinished patches in this regard -- you'll want to search the archives and the TODO list.
One thing to remember is that, that this behavior should be supported in all PLs that support domain types as variables.
