Re: DEFAULT of domain ignored in plpgsql (8.4.1)
От | Gurjeet Singh |
---|---|
Тема | Re: DEFAULT of domain ignored in plpgsql (8.4.1) |
Дата | |
Msg-id | 65937bea0911210827m61d1e781i3d6cf90e06c79e18@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DEFAULT of domain ignored in plpgsql (8.4.1) (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: DEFAULT of domain ignored in plpgsql (8.4.1)
|
Список | pgsql-hackers |
On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus <josh@agliodbs.com> wrote:
The function's DEFAULT parameter should take precedence over the default of the domain.
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..
One thing to remember is that, that this behavior should be supported in all PLs that support domain types as variables.
Best regards,I don't think there's a lot of risk of code breakage; few people use
> 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?
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.
--
Lets call it Postgres
EnterpriseDB http://www.enterprisedb.com
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
Twitter: singh_gurjeet
Skype: singh_gurjeet
Mail sent from my BlackLaptop device
В списке pgsql-hackers по дате отправления: