/
IDEAS
81 lines (55 loc) · 3.42 KB
/
IDEAS
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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
Ways to get Parrot in your Postgres database:
* Embedd One VM per postgres backend
** load via a shared library (.so or .dylib)
* pure NCI
Notes for the PostgreSQL side:
* PL/LOLCODE http://pgfoundry.org/projects/pllolcode/
* http://www.postgresql.org/docs/8.4/static/xfunc-c.html
* http://www.postgresql.org/docs/8.4/static/plhandler.html
* http://developer.postgresql.org/pgdocs/postgres/parser-stage.html
* http://www.postgresonline.com/journal/index.php?/archives/6-Language-Architecture-in-PostgreSQL.html
Notes for the Parrot side:
* mod_parrot http://www.parrot.org/mod_parrot
* Parrot Core Embedding Docs: http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd10_embedding.pod.html
Other random semi-related stuff
* PL/R http://www.joeconway.com/plr/
* PL/Scheme http://plscheme.projects.postgresql.org/
* R in Postgres: http://www.omegahat.org/RSPostgres/
Things we'll need to build:
1) A C-based shared object containing at minimum a "language handler" function.
This is what PostgreSQL calls when trying to execute a PL/Parrot function, and
it's responsible for invoking the interpreter. This will probably be called
plparrot.so
2) Some sort of module PL/Parrot functions can import which will allow them to
talk to the database.
There will be some interesting interaction, perhaps, between these two modules.
The handler function is the only one that will have capacity to talk to the
database (barring opening a new connection to the database from Parrot, but
that would obviate the benefits of a procedural language). Presumably the .so
will need to export functions to the module to allow it to get to the database.
The first step in all this is to get the handler function working, so you can
run Parrot routines that don't access the database, you can pass them data, and
they can return data. Second will be to make the database interaction module
work.
Update:
01:54 eggyknap : So presumably we can write, in nqp-rx, something that can export some functions and be loaded by any function written in a
language parrot understands... and presumably those exported functions can actually wrap C code we'll write in the C bits
of pl/parrot?
01:54 dukeleto : eggyknap: that sounds about right
01:55 dukeleto : eggyknap: please write that down somewhere :)
01:55 eggyknap : Sweet... 'cuz that's how it's gotta work, AFAICS.
David Wheeler suggests shelling out directly to psql from the test harness instead of using pg_prove. Fewer dependencies!
This is how the pgTAP plugin for Test::Harness does it:
http://github.com/AndyA/Test-Harness/blob/master/lib/TAP/Parser/SourceHandler/pgTAP.pm
psql
--no-psqlrc
--no-align
--quiet
--pset pager=
--pset tuples_only=true
--set ON_ERROR_ROLLBACK=1
--set ON_ERROR_STOP=1
IDEAS FOR EXPOSING POSTGRES FUNCTIONS IN PL/PARROT
* At minimum we need to expose a set of functions: elog(), and SPI stuff, and possibly even utility functions to get pieces of PostgreSQL data types that might not map cleanly to Parrot HLLs
* One possibility is to create a PMC that people use to access PostgreSQL. This PMC would include methods corresponding to each of the functions we need to expose
* Alternatively we can just make the functions available somehow. The primary advantage of PMC over this method as I (eggyknap) see it, is that it seems easier to figure out how to write a PMC than to figure out how to make functions magically available in PL/Parrot functions