agora inbox for postgres@postgres.berkeley.edu
help / color / mirror / Atom feedFrom: Paul M. Aoki <aoki@cs.berkeley.edu>
To: postgres@postgres.Berkeley.EDU
Subject: [schenkel@cs.few.eur.nl: Incorporating new access methods / polygons]
Date: Fri, 16 Dec 94 05:18:05 -0800
Message-ID: <199412161318.FAA04778@faerie.CS.Berkeley.EDU> (raw)
------- 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/
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: postgres@postgres.berkeley.edu
Cc: aoki@cs.berkeley.edu
Subject: Re: [schenkel@cs.few.eur.nl: Incorporating new access methods / polygons]
In-Reply-To: <199412161318.FAA04778@faerie.CS.Berkeley.EDU>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox