Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199412161318.FAA02279@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199412161318.FAA04778@faerie.CS.Berkeley.EDU>
From: aoki@cs.berkeley.edu (Paul M. Aoki)
To: postgres@postgres.Berkeley.EDU
Reply-To: Vincent Schenkelaars <schenkel@cs.few.eur.nl>
Subject: [schenkel@cs.few.eur.nl: Incorporating new access methods / polygons]
Date: Fri, 16 Dec 94 05:18:05 -0800
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Fri, 16 Dec 94 05:18:14 -0800
Resent-XMts: smtp

------- Forwarded Message

 From:  Vincent Schenkelaars <schenkel@cs.few.eur.nl>
 To:  owner-postman@postgres.Berkeley.EDU
 Subject:  Re: Incorporating new access methods / polygons
 Date:  Fri, 16 Dec 94 08:46:16 +0100

 > Hello
 > 
 > I am working on adding additional spatial access method on Postgres and
 > have been trying to understand various source (like the source code and
 > pg.am -- thank for Paul Brown for that tip). 
 > 
 > Two questions:
 > 
 > (A) Suppose I have a new access method code written. Assume say, I just
 >     copy the R-tree code and renaming it R2-tree, residing in the
 >     directory ......./backend/access/index-r2tree. What else do I have
 >     to do to?
 > 
 First of all, you need to have a lot of courage to do this. As far as I know 
 there have been a couple of attempts but I have not heard of anyy succes 
 besides my implementation of the Reactive-tree.
 
 >     This is what I think should happen, can anyone point out any mistake?
 > 
 >     (1) Create a Makefile.inc with the following statements:
 > 
 >     .PATH: ${.CURDIR}/access/index-r2tree
 >     SRCS+= r2tget.c r2tproc.c r2tree.c r2tscan.c r2tstrat.c
 > 
 Correct. You could use some of the files of the original r-tree code. In my
 case I did not need to change the r2strat.c file so I used the r-tree functions
 inthere. You do not have to use the compile schema the postgres system uses.
 All you have to do is make .o files and .so files just like you do with adding
 functions or new user types.
 
 >     (2) Go to ..../backend/catalog/
 > 
 >     (3) Edit pg_am by adding a DATA statement to insert the access method
 >         to pg_am  
 > 
 >         DATA(insert OID = 1500 ( r2tree PGUID "o" ...........));
 >       
 >         [A unique OID (from ALL other OIDS in other pg files) will be enough, 
 >          right? Or do the range of OID matters (like I should use 1-10 for 
 >          some function etc.)?]
 > 
 
 No this is not the way to do it. I guess your proposed method works too, but
 you should be able to add a new access method without recompiling the complete
 postgres system.
 What you should do is execute the following statement:
 
 append pg_am(amname = "r2-tree",  ...... other pg_am attributes) 
 
 This results in the registration of your AM in postgres.
 
 >     (4) Edit pg_proc by adding a DATA statement to insert each interface
 >         procedure to pg_proc 
 > 
 >         DATA(insert OID = 1600 ( r2tinsert PGUID "o" ...........));
 >
 
 No you just register the functions with:
 
 define function r2tinsert(language="c", returntype = ...)
       as "your_object_library.so"
 
 Note that you don't fill in the argument type. Postgres does not know the
 type relation on the user level. To trick the system you execute the following
 query:
 replace pg_proc (pronargs = 2) where pg_proc.proname = "r2tinsert"
    
 >         [We only need to do this for the interface functions, like those
 >          needed in pg_am, right?]
 >
 Right.
 
  
 >     (5) Edit pg_amop.h, pg_amproc.h similarly to insert the tuples.
 > 
 >     (6) Edit  ...../backend/utils/builtin.h to include all the function
 >         headers:
 >          extern char* r2tinsert(); etc.
 >
 Not neccesary, 'cause youre not going to recompile the system.
  
 >     (7) If there is new selectivity functions, incoporate them
 >         into .../backend/utils/adt/selfuncs.c
 >
 No just register them in postgres just like ordinary functions.
  
 >     (8) Remake the whole thing (using bmake).
 >
 No, you don't want to do this. (-:
  
 >     Anything I missed? Messed up? Any guidelines?
 >
 You have to create an opclass for the left, right, equal, etc. operators for
 your AM (if you are using postgres types to put the index on. If you need
 a new type to index, you have to write these function and operators too.). 
  
 > (B) Polygons. The polygon functions seems to be just manipulating 
 >     bounding boxes. Is it right? Is there a package to allow really
 >     working with (multiside) polygons?
 >
 This is not right but its the way it is. There is a "old" GEO++ package at
 the postgres ftp-site. This is a GIS front end. It contains alternative
 geometric types and functions.
  
 > Hope it's not too long. Thanks a lot in advance.
 >
 It's long, but so is your path to success.
  
 > David Lin
 
 What you really need is my master's thesis. It's got all the information you 
 need. I could send you a copy if the founding organization FEL-TNO allows it.
 
 Regards,
      ____________________   Vincent F. Schenkelaars
  \  / . _   _  _   _  |	    E-mail: Schenkelaars@cs.few.eur.nl
   \/ ( ( \ (_ (-' ( \ |     
 			    "We apologize for the inconvenience"
 

------- End of Forwarded Message
--
  Paul M. Aoki          |  University of California at Berkeley
  aoki@CS.Berkeley.EDU  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU".
   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
              URL: http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/