Thread: Should we drop the "object" from ORDBMS?
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
On 26 April 2012 16:02, Jeff Davis <pgsql@j-davis.com> 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
On Wed, Apr 25, 2012 at 11:34 PM, Brendan Jurd <direvus@gmail.com> wrote: > On 26 April 2012 16:02, Jeff Davis <pgsql@j-davis.com> 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
On 26 April 2012 17:00, Chris Travers <chris.travers@gmail.com> wrote: > On Wed, Apr 25, 2012 at 11:34 PM, Brendan Jurd <direvus@gmail.com> 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
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
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.
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: ned@xtuple.com <mailto:ned@xtuple.com> Visit our company <http://www.xtuple.com>, community <http://www.xtuple.org>, and join the innovation conversation <http://www.nextbusinessblog.com>
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
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
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
2012/4/27 Jeff Davis <pgsql@j-davis.com>: > 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 (pgsql-advocacy@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-advocacy
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
> 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
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
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.