Re: extended operator classes vs. type interfaces

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extended operator classes vs. type interfaces
Date: 2010-04-09 17:13:46
Message-ID: 4BBF19FA0200002500030662@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-04-09 17:19:11 Re: extended operator classes vs. type interfaces
Previous Message Joe Conway 2010-04-09 16:16:36 Re: extended operator classes vs. type interfaces