Re: extended operator classes vs. type interfaces

Jeff Davis wrote:
> On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote:
>> I just thought that if you were adding more type information,
>> oriented aournd the types themselves rather than index AMs, some form
>> of inheritence might fit in gracefully.
>
> There are already some specific proposals for inheritance in database
> theory literature. For instance: "Databases, Types, and the Relational
> Model" by C.J. Date addresses inheritance explicitly (and the appendices
> have some interesting discussion).
>
> I'm not sure how compatible it is with SQL, though; and I am not very
> optimistic that we could accomplish such a restructuring of the type
> system while maintaining a reasonable level of backwards compatibility.
>
> Either way, I think it's a separate topic. Two types that are not
> related by any subtype/supertype relationship (like strings and ints)
> can conform to the same interface (total ordering); while the very same
> type can conform to two different interfaces.
>
> Regards,
> Jeff Davis

Well I've been doing a lot of work with range abstract data types in
Oracle lately. And I've got to say that the OO features in Oracle make
it really nice. Of course its Oracle, so its like a half baked OO in
cobol syntax, lol. But I for one think it would be great if Postgres had
object data types that had methods and could be subclassed.

For those not familiar with ADT's in Oracle, here's an example:

CREATE TYPE period AS OBJECT (
beginning DATE,
ending DATE,
CONSTRUCTOR FUNCTION period (
self IN OUT NOCOPY period,
beginning DATE,
ending DATE
) RETURN SELF AS RESULT,
-- config functions
MEMBER FUNCTION granule RETURN INTERVAL DAY TO SECOND,
MEMBER FUNCTION def_inc RETURN NUMBER,
MEMBER FUNCTION range_union(p2 period) RETURN period
...
) NOT FINAL;

CREATE TYPE date_range UNDER period (
OVERRIDING MEMBER FUNCTION granule RETURN INTERVAL DAY TO SECOND,
OVERRIDING MEMBER FUNCTION def_inc RETURN NUMBER,
...
);

Scott Bailey