Re: Should we drop the "object" from ORDBMS?

Josh Berkus wrote:
> On 4/25/12 11:02 PM, Jeff Davis wrote:
>> As far as I can tell, postgresql has the following object-relational
>> features:
>
> Um, you missed the really big one:
>
> (4) User-definable Type system, with context-sensitive operators and
> functions.
>
> It's our type system which makes us an ORDBMS. The other things are
> largely decorations.

Yes, exactly.

Its all about having proper support for user-defined types and functions on
those, and also the ability to reuse the same syntax or unqualified function
names on different types. When people say "object-relational", this is
fundamentally what they're talking about, user-defined types.

Of course, I and CJ Date would argue that features of "object-relational" are
really just features of a fully-implemented "relational", meaning user-defined
types, and so for that reason saying "object" is just a noise-word, helpful only
for marketing and nothing else.

It isn't about the syntax either. Being able to have say 2 distinct operators
"foo(Integer)" and "foo(Text)", where the system just knows when you say
"foo(x)" which to dispatch to based on the type of "x", that there is your
polymorphism, the other key "object" feature.

Writing say "x.foo" is just syntactic sugar.

On a tangent, I highly recommend using something other than "." for for any
value-method invocation syntax we might have, because "." is already widely used
in SQL to represent drilling namespaces or attributes. If it isn't already in
use for something, I suggest using "->" instead. Then, for example, we can
disambiguate at the parser level between "x.foo()" where "x" is a database
schema containing a foo() routine, and "x->foo()" where we have a method call.
In fact, the method call syntax should be nothing more than syntactic sugar,
where you get all the same polymorphism/etc goodness saying "foo(x)" instead.

As for generated columns, one should define and use those like views or
constraints, where the syntax for using them is the same as non-generated ones,
in particular no "()" suffix.