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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: permissions of external PID file
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Domains versus polymorphic functions, redux