Re: Should we drop the "object" from ORDBMS?
От | Darren Duncan |
---|---|
Тема | Re: Should we drop the "object" from ORDBMS? |
Дата | |
Msg-id | 4FA0862D.2090305@darrenduncan.net обсуждение исходный текст |
Ответ на | Re: Should we drop the "object" from ORDBMS? (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-advocacy |
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 по дате отправления: