Thread: OO future

OO future

From
Karel Zak
Date:
Hi, 
I read a presentation about Object-Oriented features in relation DBs.The nice are UDT (user defined type):
CREATE TABLE person (   name varchar(32),   address ROW( street varchar(32),                town   varchar(32)),   age
int);
INSERT INTO person VALUES ('Bill', ('Somestreet', 'Sometown'), 33);
SELECT name, address.town FROM person;

We have composite types in PostgreSQL and I think we can use it for this:
CREATE TYPE addr AS (street varchar(32), town varchar(32));CREATE TABLE person (   name varchar(32),   address addr,
ageint);
 
Comments? I nothinig found about OO in the current TODO. BTW, myexamples are only small part of possible OO features,
theothersideas are for example define PRIVATE/PUBLIC attributes in compositetypes and methods, "SELECT p.name FROM
personp WHERE p.pay->tax() > 100;"   Karel
 

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz


Re: OO future

From
Hannu Krosing
Date:
Karel Zak kirjutas K, 30.10.2002 kell 10:08:
> 
>  Hi, 
> 
>  I read a presentation about Object-Oriented features in relation DBs.
>  The nice are UDT (user defined type):
> 
>  CREATE TABLE person (
>     name varchar(32),
>     address ROW( street varchar(32),
>                  town   varchar(32)),
>     age int
>  );
> 
>  INSERT INTO person VALUES ('Bill', ('Somestreet', 'Sometown'), 33);
> 
>  SELECT name, address.town FROM person;
> 
> 
>  We have composite types in PostgreSQL and I think we can use it for this:
> 
>  CREATE TYPE addr AS (street varchar(32), town varchar(32));
>  CREATE TABLE person (
>     name varchar(32),
>     address addr,
>     age int
>  );
>  
> 
>  Comments? I nothinig found about OO in the current TODO.

I'm writing a small proposal for evoving inheritance and other OO
features in 7.4 and beyond. Will post once 7.3 is out.

> BTW, my
>  examples are only small part of possible OO features, the others
>  ideas are for example define PRIVATE/PUBLIC attributes in composite
>  types

At least the "Third Manifesto" by Date et.al. claims that PRIVATE/PUBLIC
is better left to standard access control mechanisms (GRANT/REVOKE). 

I agree to that.

> and methods, "SELECT p.name FROM person p WHERE p.pay->tax() > 100;"

The methods will probably have problems with syntax clashes with
existing stuff.

--------------
Hannu




Re: OO future

From
Karel Zak
Date:
On Wed, Oct 30, 2002 at 08:35:09AM +0200, Hannu Krosing wrote:
> >  Comments? I nothinig found about OO in the current TODO.
> 
> I'm writing a small proposal for evoving inheritance and other OO
> features in 7.4 and beyond. Will post once 7.3 is out.
Good! I look forward.

> > BTW, my
> >  examples are only small part of possible OO features, the others
> >  ideas are for example define PRIVATE/PUBLIC attributes in composite
> >  types
> 
> At least the "Third Manifesto" by Date et.al. claims that PRIVATE/PUBLIC
> is better left to standard access control mechanisms (GRANT/REVOKE). 
> 
> I agree to that.
Yes, but it expect access control pre-column and for per composite typeattribute. I understand PRIVATE as some internal
datafor methodsand it needn't a speciffic access control, because control must bedefine for methods, and other way
accessPRIVATE data is not possible.IMHO it's better.The other important thing is possibility create table from type:
CREATETABLE adresses AS address_t;
 

> > and methods, "SELECT p.name FROM person p WHERE p.pay->tax() > 100;"
> 
> The methods will probably have problems with syntax clashes with
> existing stuff.
Hmm, p.pay.tax() ?
   Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz


Re: OO future

From
Paul Ramsey
Date:
There's a nice simple book from 1999 by Stonebreaker and a technologist 
form Informix about object-relational features. PostgreSQL has 
definately started to lag on that front, while shoring up other aspects 
of the RDBMS. A simple (simple?) start might just be supporting dot 
notation and other syntactical niceties around the table-as-column concept.

We have recently had an opportunity to evaluate the object relational 
capabilities of Oracle9i, and sad to say, they have finally surpassed 
PgSQL on the OO front in this release. Very easy composite type creation 
on the command line, composite types are easily indexable based on their 
attributes (a custom type which wraps a spatial type can be indexed 
spatially, etc), function adding is easy too. Now, adding completely new 
types in C might be hell, but we haven't checked that yet :)

P.

Karel Zak wrote:
>  Hi, 
> 
>  I read a presentation about Object-Oriented features in relation DBs.
>  The nice are UDT (user defined type):
> 
>  CREATE TABLE person (
>     name varchar(32),
>     address ROW( street varchar(32),
>                  town   varchar(32)),
>     age int
>  );
> 
>  INSERT INTO person VALUES ('Bill', ('Somestreet', 'Sometown'), 33);
> 
>  SELECT name, address.town FROM person;
> 
> 
>  We have composite types in PostgreSQL and I think we can use it for this:
> 
>  CREATE TYPE addr AS (street varchar(32), town varchar(32));
>  CREATE TABLE person (
>     name varchar(32),
>     address addr,
>     age int
>  );
>  
> 
>  Comments? I nothinig found about OO in the current TODO. BTW, my
>  examples are only small part of possible OO features, the others
>  ideas are for example define PRIVATE/PUBLIC attributes in composite
>  types and methods, "SELECT p.name FROM person p WHERE p.pay->tax() > 100;"
>  
>     Karel
> 


--       __     /     | Paul Ramsey     | Refractions Research     | Email: pramsey@refractions.net     | Phone: (250)
885-0632    \_
 



Re: OO future

From
Bruce Momjian
Date:
Here is an O'Reilly article talking about Oracle's OO capabilities:
http://www.oreillynet.com/pub/a/network/2002/10/29/Feuerstein.html

---------------------------------------------------------------------------

Hannu Krosing wrote:
> Karel Zak kirjutas K, 30.10.2002 kell 10:08:
> > 
> >  Hi, 
> > 
> >  I read a presentation about Object-Oriented features in relation DBs.
> >  The nice are UDT (user defined type):
> > 
> >  CREATE TABLE person (
> >     name varchar(32),
> >     address ROW( street varchar(32),
> >                  town   varchar(32)),
> >     age int
> >  );
> > 
> >  INSERT INTO person VALUES ('Bill', ('Somestreet', 'Sometown'), 33);
> > 
> >  SELECT name, address.town FROM person;
> > 
> > 
> >  We have composite types in PostgreSQL and I think we can use it for this:
> > 
> >  CREATE TYPE addr AS (street varchar(32), town varchar(32));
> >  CREATE TABLE person (
> >     name varchar(32),
> >     address addr,
> >     age int
> >  );
> >  
> > 
> >  Comments? I nothinig found about OO in the current TODO.
> 
> I'm writing a small proposal for evoving inheritance and other OO
> features in 7.4 and beyond. Will post once 7.3 is out.
> 
> > BTW, my
> >  examples are only small part of possible OO features, the others
> >  ideas are for example define PRIVATE/PUBLIC attributes in composite
> >  types
> 
> At least the "Third Manifesto" by Date et.al. claims that PRIVATE/PUBLIC
> is better left to standard access control mechanisms (GRANT/REVOKE). 
> 
> I agree to that.
> 
> > and methods, "SELECT p.name FROM person p WHERE p.pay->tax() > 100;"
> 
> The methods will probably have problems with syntax clashes with
> existing stuff.
> 
> --------------
> Hannu
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073