Re: extended operator classes vs. type interfaces

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: extended operator classes vs. type interfaces
Дата
Msg-id 4BBF19FA0200002500030662@gw.wicourts.gov
обсуждение исходный текст
Ответ на extended operator classes vs. type interfaces  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: extended operator classes vs. type interfaces
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Given a type T, I think we'd like to be able to define a type U as
> "the natural type to be added to or subtracted from T".  As Jeff
> pointed out to me, this is not necessarily the same as the
> underlying type.  For example, if T is a timestamp, U is an
> interval; if T is a numeric, U is also a numeric; if T is a cidr,
> U is an integer. Then we'd like to define a canonical addition
> operator and a canonical subtraction operator.
As it is de rigueur for someone to escalate the proposed complexity
of an idea by at least one order of magnitude, and everyone else has
fallen down on this one:  ;-)
I've often thought that if we rework the type system, it would be
very nice to support a concept of hierarchy.  If you could
"subclass" money to have a subclass like assessable, which in turn
has subclasses of fine, fee, restitution, etc. you could then
automatically do anything with a subclass which you could do with
the superclass, and support such things as treating the sum of
various classes as the lowest common subclass.  It seems like this
sort of approach, if done right, might allow some easier way to
establish sensible operations between types (like distance / speed =
time or speed * time = distance).
Just a thought....
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: extended operator classes vs. type interfaces
Следующее
От: Robert Haas
Дата:
Сообщение: Re: extended operator classes vs. type interfaces