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

From: Darren Duncan
Subject: Re: Should we drop the "object" from ORDBMS?
Date: ,
Msg-id: 4FA0862D.2090305@darrenduncan.net
(view: Whole thread, Raw)
In response to: Re: Should we drop the "object" from ORDBMS?  (Josh Berkus)
List: pgsql-advocacy

Tree view

Should we drop the "object" from ORDBMS?  (Jeff Davis, )
 Re: Should we drop the "object" from ORDBMS?  (Brendan Jurd, )
  Re: Should we drop the "object" from ORDBMS?  (Chris Travers, )
   Re: Should we drop the "object" from ORDBMS?  (Brendan Jurd, )
 Re: Should we drop the "object" from ORDBMS?  ("Kevin Grittner", )
  Re: Should we drop the "object" from ORDBMS?  (Jeff Davis, )
 Re: Should we drop the "object" from ORDBMS?  (Peter Eisentraut, )
  Re: Should we drop the "object" from ORDBMS?  (Ned Lilly, )
  Re: Should we drop the "object" from ORDBMS?  (Jeff Davis, )
   Re: Should we drop the "object" from ORDBMS?  (Pavel Stehule, )
 Re: Should we drop the "object" from ORDBMS?  (Josh Berkus, )
  Re: Should we drop the "object" from ORDBMS?  (Jeff Davis, )
   Re: Should we drop the "object" from ORDBMS?  (Josh Berkus, )
    Re: Should we drop the "object" from ORDBMS?  (Josh Berkus, )
  Re: Should we drop the "object" from ORDBMS?  (Darren Duncan, )

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.



pgsql-advocacy by date:

From: Darren Duncan
Date:
Subject: Re: Should we drop the "object" from ORDBMS?
From: Michael Alan Brewer
Date:
Subject: Re: Need PG Geek in Charlotte