[HACKERS] uml diagrams of system catalogues
Hi all, Has anyone produced a UML diagram of the system catalogues or made a start on it? Especially in a package that outputs xml/xmi file formats, such as Argouml or dia? If so, would you be willing to share? Else if deemed a good idea might make a start myself... cheers, John ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] possible DOMAIN implementation
Hi, Tom Lane wrote: > > John Reid <[EMAIL PROTECTED]> writes: > >> Ugh. Don't overload pg_class with things that are not tables. I see no > >> reason that either pg_class or pg_attribute should be involved in the > >> definition of a domain. Make new system tables if you need to, but > >> don't confuse the semantics of critical tables. > > > This is required due to the way inheritance is currently handled? > > Not inheritance specifically. I'nm just looking at it on general design > principles: all the rows of a table should be the same kind of thing. > We shade that a little to allow views, sequences, etc, in pg_class, but > at least they're all things that have columns and so forth. These could actually be defined in pg_type (or an inherited class pg_class_def)? > > > From what I can remember inheritance works in postgresql at the class level. > > C.J. Date et al *strongly* argue that inheritance should be based on types, > > not relations/classes. This is still the case in 7.1? > > Postgres doesn't really distinguish between tables and composite types > --- there's a one-for-one relationship between 'em. So we haven't had > to think hard about that point. If we did allow composite types without > associated tables, we probably would want tables to inherit from 'em > (which would mean some rethinking of the inheritance representation). Yes. I had a superficial look at SQL99 abstract data types a while back, but didn't get very far. I didn't raise any of the issues I came across at the time as everyone was busy with the 7.1 release. My interest is primarily in GIS data storage, which is a bit more involved than most applications. Ability to define complex types without having to instantiate them (or else implement them as user defined type when they are really a class) would be especially handy for GIS schemas. Not quite sure what else yet ;-) IMHO, it is probably worth looking at this further - it seems to me that these issues will have a significant impact when dealing with implementation of the SQL99 standard, so probably easier to deal with them now/soon? FWIW, some *really sketchy* ideas from when I looked at this: 1) pg_inherits should point at pg_type 2) some (most?) of the functionality of pg_class should be moved into pg_type ((2a) maybe using inherited class pg_class_def?) 3) pg_class should purely contain relation specific stuff only (type, indexes, owner) another alternative would be introduce a new system table pg_relation for relations, making pg_class the equivalent of pg_type but used for handling complex types. Then again, this is effectively the same as (2a)? Might make sense to think about renaming the tables anyway, as to me pg_class seems to imply the class definition, rather than the instantiation. Then we would have pg_type pg_class inherits pg_type pg_relation I could forsee some real chicken or the egg problems in system initialization. How are these handled currently? cheers, John ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] possible DOMAIN implementation
Hi,
Haven't looked at this for a while, but I think some larger issues might raise
their (ugly?) heads here.
Domains are effectively types that inherit attributes of parent type, with
some additional information, so should be handled at the level of pg_type.
However might make sense to look at some other matters at the same time - I'm
thinking specifically of general inheritance and abstract data types. AFAICT,
these are all closely related. I started looking at this a while ago, but was
side-tracked by the winds of change ;-)
Tom Lane wrote:
> =?iso-8859-2?Q?Hor=E1k_Daniel?= <[EMAIL PROTECTED]> writes:
> > When a new domain is created it will:
> > - put a record into pg_type with typnam = domain name, new code for
> > typtype = 'd' and typrelid = oid of a new record in pg_class (next line)
> - put a record into pg_class to create a fictional table with a new
> > relkind ('d'?), relnatts = 1, relname can be system generated
> > (pg_d_)
>
> Ugh. Don't overload pg_class with things that are not tables. I see no
> reason that either pg_class or pg_attribute should be involved in the
> definition of a domain. Make new system tables if you need to, but
> don't confuse the semantics of critical tables.
This is required due to the way inheritance is currently handled?
> > - put a records into pg_attribute and pg_attrdef with "column
> > (attribute) definition" - real type, size, default value etc., owner
> > will the fictional table from the previous step
ditto?
> > Then it will be required to modify functions that works with types. When
> > typtype of a retrieved type is 'd' then it will perform lookups into
> > pg_class, pg_attribute and pg_attrdef to find the real definition of the
> > domain. These additional lookups will also create a performace penalty
> > of using domains.
>
> Why shouldn't this info be directly available from the pg_type row?
>From what I can remember inheritance works in postgresql at the class level.
C.J. Date et al *strongly* argue that inheritance should be based on types,
not relations/classes. This is still the case in 7.1? If the inheritance
mechanism could be changed to support types, the concept of inheritance for
classes should not be broken as these have entries in pg_type - possible some
code might be though :-(
Please note that I'm looking at forest scales (and also through the haze of
memory) - the trees might have an entirely viewpoint ;-)
cheers,
John
--
--
john reid e-mail [EMAIL PROTECTED]
technical officerroom G02, building 41
school of geosciences phone +61 02 4221 3963
university of wollongong fax +61 02 4221 4250
uproot your questions from their ground and the dangling roots will be
seen. more questions!
-mentat zensufi
apply standard disclaimers as desired...
--
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CORBA and PG
Hi, This was mentioned a while back on this list (pg hackers) - thanks to whoever provided the pointer :-) I have not yet looked at it in depth, though that is high on my list of TO-DO's. It is released under an apache style licence. Any reason why there are no pointers to it on the PostgreSQL related projects or interfaces pages? project page: http://4suite.org/index.epy docs on ODMG support: http://services.4Suite.org/documents/4Suite/4ODS-userguide >From project page: "4Suite is a collection of Python tools for XML processing and object database management. It provides support for XML parsing, several transient and persistent DOM implementations, XPath expressions, XPointer, XSLT transforms, XLink, RDF and ODMG object databases. 4Suite server ... features an XML data repository, a rules-based engine, and XSLT transforms, XPath and RDF-based indexing and query, XLink resolution and many other XML services. It also supports related services such as distributed transactions and access control lists. Along with basic console and command-line management, it supports remote, cross-platform and cross-language access through CORBA, WebDAV, HTTP and other request protocols to be added shortly." Drivers for PostgreSQL and Oracle are provided. BTW, page pays postgresql quite a compliment too: "PostgresQL is a brilliant, enterprise-quality, open-source, SQL DBMS." :-) Peter T Mount wrote: > Quoting Franck Martin <[EMAIL PROTECTED]>: > > > I guess these stubs are for accessing PG as a corba server... > > > > I'm trying to look to see if I can store CORBA objects inside PG, any > > ideas... > Although I've not tried it (yet) it should be possible to access Java EJB's > from corba. > > If so, then using an EJB server (JBoss www.jboss.org) you could then store them > as Entity beans. Each one would then have its own table in the database. > > Peter > > > > > Franck Martin > > Network and Database Development Officer > > SOPAC South Pacific Applied Geoscience Commission > > Fiji > > E-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > Web site: http://www.sopac.org/ > > <http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/ > > <http://fmaps.sourceforge.net/> > > > > This e-mail is intended for its addresses only. Do not forward this > > e-mail > > without approval. The views expressed in this e-mail may not be > > necessarily > > the views of SOPAC. > > > > > > > > -Original Message- > > From: Peter T Mount [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, 6 March 2001 3:52 > > To: Franck Martin > > Cc: PostgreSQL List > > Subject: Re: [HACKERS] CORBA and PG > > > > > > Quoting Franck Martin <[EMAIL PROTECTED]>: > > > > > Does anyone has pointers on CORBA and PostgreSQL? > > > > > > What is the story ? > > > > There's some old stubs for one of the orbs somewhere in the source > > (C/C++) > > > > Also the old JDBC/Corba example is still there > > (src/interfaces/jdbc/example/corba) > > > > Peter > > > > > > -- > > Peter Mount [EMAIL PROTECTED] > > PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ > > RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/ > > > > -- > Peter Mount [EMAIL PROTECTED] > PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ > RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/ > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- -- john reid e-mail [EMAIL PROTECTED] technical officerroom G02, building 41 school of geosciences phone +61 02 4221 3963 university of wollongong fax +61 02 4221 4250 uproot your questions from their ground and the dangling roots will be seen. more questions! -mentat zensufi apply standard disclaimers as desired... -- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
