Re: VARIANT / ANYTYPE datatype

Robert Haas wrote:
> On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
> <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
>> On Tue, May 10, 2011 at 5:19 PM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
>>> Examples of open union types could be number, which all the numeric types
>>> compose, and so you can know say that you can use the generic numeric
>>> operators on values you have simply if their types compose the number union
>>> type, and it still works if more numeric types appear later. Likewise, the
>>> string open union could include both text and blob, as both support
>>> catenation and substring matches or extraction, for example.
>>>
>>> This would aid to operator overloading in a generic way, letting you use the
>>> same syntax for different types, but allowing types to mix is optional; eg,
>>> you could support "add(int,int)" and "add(real,real)" without supporting
>>> "add(int,real)" etc but the syntax "add(x,y)" is shared, and you do this
>>> while still having a strong type system; allowing the mixing is optional
>>> case-by-case.
>> Coming from a Haskell perspective, this is a great idea, but I don't
>> think the "union" feature should be used to implement it.
>
> I'm unclear what the point of such a feature would be. A union of all
> the common numeric types is not much different from the existing type
> "numeric".

In the case of the "open union" numeric, one point is that users or extensions
could come up with new types that add themselves to the union, for example say a
type for complex numbers (I didn't see a built-in such).

But I'm just citing numeric as an example; there would be a lot more in
practice, potentially one for every individual type, so for example if operators
were defined for the open union rather than for the base type, then
users/extensions could define their own types and easily declare "you can use it
like this type" but its different in some important way, which may just be an
implementation difference. Operations that don't care about the differences can
just be written against the open union type where they just work and those that
do care can be more specific.

Joseph Adams said:
> Coming from a Haskell perspective, this is a great idea, but I don't
> think the "union" feature should be used to implement it. Closed
> unions correspond to algebraic data types in Haskell, e.g.:
>
> data Ordering = LT | EQ | GT
>
> while open unions are better-suited to type classes:
>
> (+) :: (Num a) => a -> a -> a

While closed unions would often be used for your first examlpe, I see they're
still useful for type classes as well. Especially in the face of open unions
being available, the closed unions let users say, no, I don't really want the
meaning of this union type to change just because someone else declares a new
type in scope (that adds itself to the union). For example, one could declare a
system_numeric closed union type that only includes Pg built-in numerics and
users of that can be confident that nothing about it will change later unless
the definition of system_numeric itself or the types it unions are changed. But
open unions would be preferred in places they wouldn't cause trouble, where you
want to allow easier user extensibility.

> I, for one, would like to see PostgreSQL steal some features from
> Haskell's type system. PostgreSQL seems to implement a subset of
> Haskell's system, without type classes and where functions can have
> only one type variable (anyelement).

I think that Haskell and other functional languages have a lot to teach
relational DBMSs and I see them as being highly compatible.

-- Darren Duncan