Re: [GENERAL] Re: Postgresql OO Patch
От | Chris Bitmead |
---|---|
Тема | Re: [GENERAL] Re: Postgresql OO Patch |
Дата | |
Msg-id | 392B1A5E.466EB9EB@nimrod.itg.telecom.com.au обсуждение исходный текст |
Ответ на | Re: [GENERAL] Re: Postgresql OO Patch (Marten Feldtmann <marten@feki.toppoint.de>) |
Ответы |
Re: [GENERAL] Re: Postgresql OO Patch
|
Список | pgsql-hackers |
> - the OID (SEQUENCE's) are useless (ok, I say it again and again). Give > PostgreSQL the OID and ask PostgreSQL to return the attributes of this > object. Perhaps even with class informations ! > > PostgreSQL is not able to do that ! Think about this and you see > the usage of the OID in perhaps a different way :-) > > Therefore: for object system you need complete other types of object > identification numbers. I agree, that's why I have suggested an implied super-class "Object" for all postgresql objects. Then you could do "SELECT ** FROM object WHERE oid=?". The ability to place an index over sub-class hierarchies (in this case oid for all objects) would get the good performance. > - query over a hierarchy of classes ! See the example above ! Until > you're not able to return multiple sets you get too much garbage or > you need to many queries or you need much more disc-space, depending > of the way you wrap classes to tables. This feature is a CRITICAL > one ! This may push the performance, depending how it is done. Yep. > - for associations (m:n) I still need additional help tables, but > that is ok :-) Actually, postgres can have arrays of oids which is the ODBMS way of handling associations. Last I looked there are some contrib functions for doing things like ... CREATE TABLE foo( bar [] ); CREATE TABLE bar( ... etc); SELECT bar.** from bar, foo where array_in(bar.oid, foo.bar) and foo.oid=?". In other words, to retrieve all the objects in a list. (forget the actual function name). > - no support for tree structures ! AGAIN AGREE! Original postgres had a syntax "SELECT* from foo" to get a transitive closure on a tree! Why this was removed (argh!) I can only guess. > - more powerful statements DDL to change the structure of a database ! Yep, important. > - no support to inform the client about changes inthe database ! Havn't even looked at that.
В списке pgsql-hackers по дате отправления: