Re: Domains versus polymorphic functions, redux
От | Kevin Grittner |
---|---|
Тема | Re: Domains versus polymorphic functions, redux |
Дата | |
Msg-id | 4DE8E757020000250003E104@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Domains versus polymorphic functions, redux (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Domains versus polymorphic functions, redux
Re: Domains versus polymorphic functions, redux |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > The real crux of the issue here is: under what circumstances > should we look through the domain wrapper around an underlying > type, and under what circumstances should we refrain from doing > so? I don't know if this is the intent of domains in the SQL standard, but I find them useful to "extend" other types (in the object-oriented sense). "CaseNoT" *is a* varchar(14), but not every varchar(14) is a "CaseNoT". In my view, behaviors should be determined based on that concept. In the long run, it would be fabulous if a domain could extend another domain -- or event better, multiple other domains with the same base type. DOT hair color code and DOT eye color code domains might both extend a DOT color codes domain. Another long-range nicety would be something which I have seen in some other databases, and which is consistent with the inheritance theme, is that you can't compare or assign dissimilar domains -- an error is thrown. So if you try to join from the eye color column in a person table to the key of a hair color table, you get an error unless you explicitly cast one or both of them to the common type. I know that doesn't directly answer the question, but I think it provides some framework for making choices.... -Kevin
В списке pgsql-hackers по дате отправления: