Thread: Object Relational features in PostgreSQL

> Hi everyone. I just finished a course on PostgreSQL and I found out that
> PostgreSQL doesn't provide any object relational features (as claimed in
> the official documentation), except table inheritance and very limited
> user defined types (I defined a UDT with 2 attributes and couldn't use
> it in a table, and the trainer said it must contain 1 attribute at most
> so that it can be used (as a column) in tables)
>
>
> So my question is whether there is (or will be) any support for (any of)
> the following:
>
> More flexible user defined types and support for these in tables
>
> Type inheritance
>
> REF and DEREF data types
>
> Nested tables
Postgres has arrays - will that work?  After all a table is just an array :)

>
> Polymorphism and more flexible casting of objects (like the TREAT
> function, not only the ONLY function)
>
> Typed tables (create table X of type Y)
>
> Object views
Postgres has views.

>
> User defined functions (encapsulated in the body of a user defined type)
Postgres has api's in several different languages -
http://www.postgresql.org/docs/current/static/xplang.html
The best thing about it is you can write your own functions tailored to
your needs.

>
>
>
> I would be really thankful for any fast reply, because I need to report
> to the management whether a migration to PostgreSQL is both efficient
> and possible or not.

It would be helpful to know what db you're comparing it against so a more
informed response can be provided.  I think a lot of your anwers are out
there - you need to get both feet wet and solve a specific problem with it
to determine if it's right for your needs.

The docs http://www.postgresql.org/docs/ provide a great deal of
information which should help you.  Also the mailing lists at
http://www.postgresql.org/lists.html are very helpful and answer many
questions of those new to postgres.

Regards,

Fred

--- Robert Abi Saab <RSaab@ccc.gr> wrote:

> So my question is whether there is (or will be) any
> support for (any of)
> the following:
>
> More flexible user defined types and support for
> these in tables
>
> Type inheritance
>
> REF and DEREF data types
>
> Nested tables
>
> Polymorphism and more flexible casting of objects
> (like the TREAT
> function, not only the ONLY function)
>
> Typed tables (create table X of type Y)
>
> Object views
>
> User defined functions (encapsulated in the body of
> a user defined type)
>
>
>
> I would be really thankful for any fast reply,
> because I need to report
> to the management whether a migration to PostgreSQL
> is both efficient
> and possible or not.

Out of curiosity, what makes these features
indispensable to your project?  Are you seeking to
migrate from a DBMS that already supports those
features, and if so, what is that?

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

This will be the topic of a talk I'll be giving at OSCON in July.

The extent of Object implementation in PostgreSQL
is not as simplistic as your analysis makes it.  The Object
side of object-relational includes creating datatypes which in
turn are first class objects to be used in a relational database system.
Those first class objects have structure (class), functions
(methods, operators and indexes).  The relatively recent addition
of DOMAIN support enable creating subclasses of existing types,
usually base types.

PG's implementation of inheritance is not a full OO
definition of inheritance and is contrary to Codd&Date&Darwin's
specifications for inheritance.  There were other ORDBMS that did
differently or to deeper extents.

For a good understanding of some of the features you are mentioning
and as a comparison to PostgreSQL's implementation see
Paul G. Brown's book "Object-Relational Database Management: A Plumber's Guide".

I would be happy to help with additional information about the
extent of the O part or ORDBMS to help your management team.

elein
============================================================
elein@varlena.com        Varlena, LLC        www.varlena.com

          PostgreSQL Consulting, Support & Training

PostgreSQL General Bits   http://www.varlena.com/GeneralBits/
=============================================================
"Sometimes we are confronted with more data than we can really use,
and it may be wisest to forget and to destroy most of it"
-- Donald Knuth, The Art of Computer Programming


On Mon, Jan 26, 2004 at 10:01:19AM +0200, Robert Abi Saab wrote:
> Hi everyone. I just finished a course on PostgreSQL and I found out that
> PostgreSQL doesn??t provide any object relational features (as claimed in the
> official documentation), except table inheritance and very limited user defined
> types (I defined a UDT with 2 attributes and couldn??t use it in a table, and
> the trainer said it must contain 1 attribute at most so that it can be used (as
> a column) in tables)
>
>
>
> So my question is whether there is (or will be) any support for (any of) the
> following:
>
> More flexible user defined types and support for these in tables
>
> Type inheritance
SEE Domains
>
> REF and DEREF data types
>
See OIDS

> Nested tables
>
See row types and/or arrays. Row types are not currently valid
to store in a column.

> Polymorphism and more flexible casting of objects (like the TREAT function, not
> only the ONLY function)
>
> Typed tables (create table X of type Y)
>
See named types.

> Object views
>
We have this but you may not recognize it as such.

> User defined functions (encapsulated in the body of a user defined type)
>
This is an implementation detail. The functions are linked to
the type in the type definition.
>
>
> I would be really thankful for any fast reply, because I need to report to the
> management whether a migration to PostgreSQL is both efficient and possible or
> not.
>

>
>
>
>
>
>

Well in fact we're currently using SQL server 2000, which doesn't
support object oriented technology; however, I was researching the
possibility of migrating to a database that provides the features I
mentioned, as, although not 100% crucial to the application, they fit
pretty well with the nature of the 3d construction framework we're
developing.