Re: extended operator classes vs. type interfaces - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: extended operator classes vs. type interfaces
Date
Msg-id 4BBF19FA0200002500030662@gw.wicourts.gov
Whole thread Raw
In response to extended operator classes vs. type interfaces  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: extended operator classes vs. type interfaces  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: extended operator classes vs. type interfaces
Next
From: Robert Haas
Date:
Subject: Re: extended operator classes vs. type interfaces