=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