Subject: Future complex type attributes

From: [email-masked] (John Campbell)
Date: Thu, 17 Dec 92 14:07:46 -0800

The release notes for version 4.0 state:

       As a side effect of the improved  support  for  func-
    tions,  it  is  not  possible in Version 4.0 to create a
    relation which has an attribute that  is  of  a  complex
    (tuple)  type.   For  example, the addattr command shown
    above is illegal in this release of POSTGRES, since  the
    type  of the attribute being added is person, and person
    is a class.  Support for  attributes  of  complex  types
    will be reintroduced in a future release of POSTGRES.

I wonder if someone could expand on this statement a bit.  I believe
not being able to state complex types directly to be confusing, 
especially considering the following articles:

   _Extending_A_Data_Base_System_With_Procedures_   (page 2)

   create EMP (name=c10, age=i4, salary=f8, hobbie=procedure)
   append to EMP (name="Smith", age=40, salary=10000,
      hobbies="retrieve(SOFTBALL.all) where SOFTBALL.name="Smith")

  _The_Implementation_of_Postgres_  (page 7)
   
   define function set_of_DEPT as 
      retrieve (DEPT.all) where DEPT.floor = $.floor
   create FLOORS (floor=i2, depts=set_of_DEPT)
   retrieve (EMP.name) where EMP.dept.floor = 1

   "Each POSTQUEL function is automatically a constructed type."

   create PERSON (name=c12, hobbies=POSTQUEL)
  
  _The_Postgres_Data_Model_   (page 11)

   create STUDENT (Name=text, Majors=postquel, ...)
   append STUDENT (Name="Smith", Majors =
       "retrieve (D.all) from D in DEPARTMENT
        where D.Name = "Math" or D.Name = "CS" ")
   retrieve (S.Name, S.Majors.Name) from S in STUDENT
   execute (S.Majors) from S in STUDENT
      where S.Name = "Smith"

Four different methods of declaring a procedure type (hobbie=procedure,
depts=set_of_DEPT, hobbies=POSTQUEL, Majors=postquel) are documented, none 
of which currently work in Postgres 4.0.1.

I was extremely glad to find the above Release Notes statement, since 
putting the complex type directly into the class seems more natural and 
easier for the end user than having separate functions not visibly bound
to the classes.

PS  What is type "regproc"?

-- 
	John Campbell               [email-masked]
        [email-masked]      [email-masked]

---

From: <[email-masked]>
Date: Thu, 17 Dec 92 16:48:12 PST

In message <[email-masked]> you write:

> I wonder if someone could expand on this statement a bit.

here's a translation:

we screwed up and accidentally removed support for nested complex types
in a furious push to get functions working just before the 4.0 release date.
adding support for postquel functions required several internal data
structures to be redesigned.  one of the structures lost an element that
was required for support of nested complex types in the process.

note that you can define postquel functions (methods) on classes, and
that these functions can return complex types.

> I believe
>    [...]

there is not, and has never been, any intention to withdraw support
for these.  we intend to provide the services described in the papers
you cite.  we're furiously working to reintroduce this support at
present.

> PS  What is type "regproc"?

internally, it's a four-byte quantity that is the object id of some
tuple in the pg_proc table.  conceptually, it's a registered procedure;
postgres searches the pg_proc table for the supplied object id internally,
and uses the procedure's name in its in and out functions.

					mike