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

From:
Jeff Davis
Date:

As far as I can tell, postgresql has the following object-relational
features:

(1) OIDs -- no longer on by default for user tables, and I can't
remember seeing OIDs recommended for users. Used in system tables, but
the main special property of OIDs (that they are hidden) is annoying
more than anything else. Who wants to select from a system table without
seeing the OIDs?

(2) Inheritance -- useful feature, mostly for partitioning. Occasionally
suggested to model actual inheritance in the OO sense, but often as one
of a couple alternatives.

(3) Dot function call syntax: "select foo.count from foo" -- surprising
to most people, and I don't recall ever seeing it suggested for actual
use. I would go so far as to say we should deprecate this syntax,
because I think it's more likely to be some kind of mistake than
anything else.

Given all this, why do we still call postgres an object-relational
system (in the first sentence of our "About" page)? Is it time to drop
"object" and just call ourselves a relational (and/or SQL) system? If
someone comes to postgres for our OO support, they are probably going to
be disappointed.

Thoughts?

Regards,
    Jeff Davis


From:
Brendan Jurd
Date:

On 26 April 2012 16:02, Jeff Davis <> wrote:
> As far as I can tell, postgresql has the following object-relational
> features:
>
...

> (3) Dot function call syntax: "select foo.count from foo" -- surprising
> to most people, and I don't recall ever seeing it suggested for actual
> use. I would go so far as to say we should deprecate this syntax,
> because I think it's more likely to be some kind of mistake than
> anything else.

Sometime in the distant past (can't find it now), I raised the idea of
having "methods" registered on a table.  If we are to pursue the
analogy of a table being like an object class, and a record being like
an object instance, well we've got the attributes covered, but we
don't have the methods.  My pipedream was that these methods could be
listed in \d and executed using dot call syntax.  So you could define
something like "FUNCTION age_years(person, date) RETURNS int" and then
call it like:

SELECT p.age_years(date '2012-05-01')
FROM person p

As I recall, my idea did not achieve escape velocity, but I still
think it would a) extend the dot-call syntax to a more useful pattern,
b) bolster our justification for the "O" in "ORDBMS", and c) actually
be kind of awesome.

On the broader question, I think you're right that our "O" is a little
bit tenuous.  But I take that as an incentive to make Postgres more
object-y, rather than an incentive to drop the "O".

Cheers,
BJ

From:
Chris Travers
Date:

On Wed, Apr 25, 2012 at 11:34 PM, Brendan Jurd <> wrote:
> On 26 April 2012 16:02, Jeff Davis <> wrote:
>> As far as I can tell, postgresql has the following object-relational
>> features:
>>
> ...
>
>> (3) Dot function call syntax: "select foo.count from foo" -- surprising
>> to most people, and I don't recall ever seeing it suggested for actual
>> use. I would go so far as to say we should deprecate this syntax,
>> because I think it's more likely to be some kind of mistake than
>> anything else.
>
> Sometime in the distant past (can't find it now), I raised the idea of
> having "methods" registered on a table.  If we are to pursue the
> analogy of a table being like an object class, and a record being like
> an object instance, well we've got the attributes covered, but we
> don't have the methods.  My pipedream was that these methods could be
> listed in \d and executed using dot call syntax.  So you could define
> something like "FUNCTION age_years(person, date) RETURNS int" and then
> call it like:
>
> SELECT p.age_years(date '2012-05-01')
> FROM person p
>
> As I recall, my idea did not achieve escape velocity, but I still
> think it would a) extend the dot-call syntax to a more useful pattern,
> b) bolster our justification for the "O" in "ORDBMS", and c) actually
> be kind of awesome.

Dot syntax should be replaced by something less ambiguous, though.
The problem is that you currently have issues in some versions of Pg
where p.name might be the name of the person, or it might be the p
record cast as something almost identical to varchar(63).......  The
only reason this is not an issue on more recent versions of Pg is that
implicit casting to text types has been dropped so this doesn't really
address the underlying problem.
>
> On the broader question, I think you're right that our "O" is a little
> bit tenuous.  But I take that as an incentive to make Postgres more
> object-y, rather than an incentive to drop the "O".

I would agree there.

Best Wishes,
Chris Travers

From:
Brendan Jurd
Date:

On 26 April 2012 17:00, Chris Travers <> wrote:
> On Wed, Apr 25, 2012 at 11:34 PM, Brendan Jurd <> wrote:
>> SELECT p.age_years(date '2012-05-01')
>> FROM person p
>>
>> As I recall, my idea did not achieve escape velocity, but I still
>> think it would a) extend the dot-call syntax to a more useful pattern,
>> b) bolster our justification for the "O" in "ORDBMS", and c) actually
>> be kind of awesome.
>
> Dot syntax should be replaced by something less ambiguous, though.
> The problem is that you currently have issues in some versions of Pg
> where p.name might be the name of the person, or it might be the p
> record cast as something almost identical to varchar(63).......  The
> only reason this is not an issue on more recent versions of Pg is that
> implicit casting to text types has been dropped so this doesn't really
> address the underlying problem.

The "method" dot-call syntax in my suggestion would always have
parentheses, p.name() for example, so I don't think it suffers from
the same ambiguity as the historical dot-call syntax.

Regardless, I don't know how we could replace the dot in the syntax.
Wouldn't it be unprecedented to have an OO syntax which uses a
different operator to reference attributes than the one to reference
methods?  That would really drain much of the notational convenience
out of the feature.

Cheers,
BJ

From:
"Kevin Grittner"
Date:

Chris Travers  wrote:

>>> (3) Dot function call syntax: "select foo.count from foo" --
>>> surprising to most people, and I don't recall ever seeing it
>>> suggested for actual use. I would go so far as to say we should
>>> deprecate this syntax, because I think it's more likely to be
>>> some kind of mistake than anything else.

> Dot syntax should be replaced by something less ambiguous, though.
> The problem is that you currently have issues in some versions of
> Pg where p.name might be the name of the person, or it might be the
> p record cast as something almost identical to varchar(63).......
> The only reason this is not an issue on more recent versions of Pg
> is that implicit casting to text types has been dropped so this
> doesn't really address the underlying problem.

We use dot syntax heavily, and I consider it a valuable feature.  For
example, names are stored in our database with separate columns for
last name, first name, middle name, suffix (Jr., III, etc.), but we
want to put those together in a canonical form for searching.  Prior
to PostgreSQL we have a trigger-maintained column in the database for
this for each name.  With PostgreSQL we were able to replace the
column with a function without changing any of our application code
or the queries they use.

I would be very unhappy to see this feature deprecated or removed.  I
would much rather see functions which qualify as "generated columns"
(i.e., they have as their only parameter the record type of a table)
listed in the \d display for a table.

Let's not break things which work just fine now.

-Kevin

From:
Peter Eisentraut
Date:

On ons, 2012-04-25 at 23:02 -0700, Jeff Davis wrote:
> As far as I can tell, postgresql has the following object-relational
> features:

> (1) OIDs

> (2) Inheritance

> (3) Dot function call syntax

I think having composite types and functions using them also belongs
there.

> Given all this, why do we still call postgres an object-relational
> system (in the first sentence of our "About" page)?

I think it's still a good mission statement of sorts, even if most
people don't use all the features.



From:
Ned Lilly
Date:

xTuple uses several inheritance features, and it's a big part of the
value-add for us.

(plug: come see John's talk at pgCon to learn more :)



On 4/26/2012 12:27 PM, Peter Eisentraut wrote:
> On ons, 2012-04-25 at 23:02 -0700, Jeff Davis wrote:
>> As far as I can tell, postgresql has the following object-relational
>> features:
>> (1) OIDs
>> (2) Inheritance
>> (3) Dot function call syntax
> I think having composite types and functions using them also belongs
> there.
>
>> Given all this, why do we still call postgres an object-relational
>> system (in the first sentence of our "About" page)?
> I think it's still a good mission statement of sorts, even if most
> people don't use all the features.
>
>
>

--
Ned Lilly
President and CEO
xTuple
119 West York Street // Norfolk, VA 23510
tel. 757.461.3022 x101 // email:  <mailto:>
Visit our company <http://www.xtuple.com>, community
<http://www.xtuple.org>, and join the innovation conversation
<http://www.nextbusinessblog.com>


From:
Josh Berkus
Date:

On 4/25/12 11:02 PM, Jeff Davis wrote:
> As far as I can tell, postgresql has the following object-relational
> features:
>
> (1) OIDs -- no longer on by default for user tables, and I can't
> remember seeing OIDs recommended for users. Used in system tables, but
> the main special property of OIDs (that they are hidden) is annoying
> more than anything else. Who wants to select from a system table without
> seeing the OIDs?
>
> (2) Inheritance -- useful feature, mostly for partitioning. Occasionally
> suggested to model actual inheritance in the OO sense, but often as one
> of a couple alternatives.
>
> (3) Dot function call syntax: "select foo.count from foo" -- surprising
> to most people, and I don't recall ever seeing it suggested for actual
> use. I would go so far as to say we should deprecate this syntax,
> because I think it's more likely to be some kind of mistake than
> anything else.

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.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

From:
Jeff Davis
Date:

On Thu, 2012-04-26 at 07:12 -0500, Kevin Grittner wrote:
> We use dot syntax heavily, and I consider it a valuable feature.  For
> example, names are stored in our database with separate columns for
> last name, first name, middle name, suffix (Jr., III, etc.), but we
> want to put those together in a canonical form for searching.  Prior
> to PostgreSQL we have a trigger-maintained column in the database for
> this for each name.  With PostgreSQL we were able to replace the
> column with a function without changing any of our application code
> or the queries they use.

Interesting hack; I hadn't thought of that.

I don't quite understand what you are advocating below:

> I would be very unhappy to see this feature deprecated or removed.  I
> would much rather see functions which qualify as "generated columns"
> (i.e., they have as their only parameter the record type of a table)
> listed in the \d display for a table.

But if you are saying we should have explicit support for generated
columns, that sounds reasonable to me. That matches more closely what
you are trying to do, and keeps the namespace cleaner.

Another concept similar to generated columns is if we had simple-to-use
updatable views.

Regards,
    Jeff Davis


From:
Jeff Davis
Date:

On Thu, 2012-04-26 at 19:27 +0300, Peter Eisentraut wrote:
> I think having composite types and functions using them also belongs
> there.

I don't see that as particularly object-oriented. C has structs. But I
can see how it's somewhat "in the spirit of" OO.

> > Given all this, why do we still call postgres an object-relational
> > system (in the first sentence of our "About" page)?
>
> I think it's still a good mission statement of sorts, even if most
> people don't use all the features.

The reason why I brought this up is because it seems like we've been
moving steadily *away* from these concepts the entire time I've been
involved in postgres. I don't have that strong of an opinion on the
subject, but it seems disingenuous to use "object" as the first word in
the description.

Regards,
    Jeff Davis


From:
Pavel Stehule
Date:

2012/4/27 Jeff Davis <>:
> On Thu, 2012-04-26 at 19:27 +0300, Peter Eisentraut wrote:
>> I think having composite types and functions using them also belongs
>> there.
>
> I don't see that as particularly object-oriented. C has structs. But I
> can see how it's somewhat "in the spirit of" OO.

The term object-oriented has different sense for programming languages
and in databases.

See a Stonebraker's idea "Object Relational Databases"

http://www.service-architecture.com/object-oriented-databases/articles/stonebrakers_dbms_matrix.html

Regards

Pavel Stehule

>
>> > Given all this, why do we still call postgres an object-relational
>> > system (in the first sentence of our "About" page)?
>>
>> I think it's still a good mission statement of sorts, even if most
>> people don't use all the features.
>
> The reason why I brought this up is because it seems like we've been
> moving steadily *away* from these concepts the entire time I've been
> involved in postgres. I don't have that strong of an opinion on the
> subject, but it seems disingenuous to use "object" as the first word in
> the description.
>
> Regards,
>        Jeff Davis
>
>
> --
> Sent via pgsql-advocacy mailing list ()
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy

From:
Jeff Davis
Date:

On Thu, 2012-04-26 at 12:48 -0700, Josh Berkus wrote:
> 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.

Again, I don't see what is particularly "object-oriented" about PG's
extensible type system.

I can see that "object-oriented" has been redefined so much that it can
mean anything. So, I suppose it doesn't hurt to leave it in the
description.

Regards,
    Jeff Davis




From:
Josh Berkus
Date:

> I can see that "object-oriented" has been redefined so much that it can
> mean anything.

Indeed.  Just take a survey of programming languages.

> So, I suppose it doesn't hurt to leave it in the
> description.

Well, it's easier to say than "Not-Just-A-Relational Database Management
System" ;-)

Or maybe Relational++ database?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

From:
Josh Berkus
Date:

On 4/30/12 3:40 PM, Josh Berkus wrote:
>
>> I can see that "object-oriented" has been redefined so much that it can
>> mean anything.
>
> Indeed.  Just take a survey of programming languages.

Oh, and also: Object-Relational != Object-Oriented

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

From:
Darren Duncan
Date:

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.