forked from leto/plparrot
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathROADMAP
39 lines (29 loc) · 1.74 KB
/
ROADMAP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
=head1 PL/Parrot ROADMAP
This document describes the roadmap for PL/Parrot. Please be as specific as possible.
* Datatype marshalling is another big step -- eggyknap knows about this stuff.
Function parameters need to be converted from pgsql Datum types to something
Parrot can both understand and have access to. The function's return value(s)
then need to be converted back to Datums.
This has been accomplished for integers, floats and string types. More code
needs to be written for all of the various PG datatypes. It also needs
to be thought out how HLL's deal with datatype conversion.
* Make installation and configuration easier
In general, there should be a "Parrot way" to install PL/Parrot (via
Plumage) and a "Postgres way" (whatever that is) to keep people in both
camps happy.
* Implement spi_exec_query() for PIR
This involves many intermediate steps that should be listed in detail here.
eggyknap's version:
* In PL/Perl, there's some XS code to allow PL/Perl functions access to
spi_exec_query and several other SPI functions (the complete list of
which is here:
http://www.postgresql.org/docs/current/static/spi.html). PL/Python
creates some Python function objects and registers them with the
Python interpreter. Presumably for Parrot, we'll create a compiled
module Parrot code can load, containing those functions. I've no idea
how to build such a thing.
eggyknap idea:
Originally I'd thought we'd provide some module or something users
would load, and then use for database access. Perhaps it makes more
sense to build a PMC that provides db access functions, and make it
available in the default namespace