Access to libpq from Parrot
Jonathan Leto
eggyplant++ was asking on IRC about how to access Postgres C API
functions from Parrot. You should look at these files:
runtime/parrot/library/postgres.declarations
runtime/parrot/library/postgres.pasm
runtime/parrot/library/postgres.pir
t/library/pg.t
Duke
--
Jonathan "Duke" Leto
jona...@leto.net
http://leto.net
Joshua Tolley
thought Id mention that we won't be using libpq, which is for stuff that
doesn't already live in the backend. Which is not to say that I think these
files won't turn out to be helpful; I just mention it to help head off
possible confusion.
Jonathan Leto
Yes, I agree. Those files are just an example of getting access to a C
library from PIR.
Duke
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvhdNYACgkQRiRfCGf1UMMR4ACgj6BtK2fdXhgC0r5CQmNCy3y8
> hOcAnReBtA+HoE0pRf0CISZRMBbnFmHv
> =c6oy
> -----END PGP SIGNATURE-----
Joshua Tolley
>
> eggyplant++ was asking on IRC about how to access Postgres C API
> functions from Parrot. You should look at these files:
>
> runtime/parrot/library/postgres.declarations
> runtime/parrot/library/postgres.pasm
> runtime/parrot/library/postgres.pir
> t/library/pg.t
So, since when am I eggy*plant*? :)
I poked through those files for a bit, and they seem to make sense, though I'm
not sure how all the parts fit together. For instance, I can say "parrot
postgres.pir" and get no "OMGFAIL!!1" output. With the -v option, it even
seems to run successfully. But, not astonishingly, it doesn't do anything.
I assume what this is doing is creating a namespace called "Pg" and filling it
with objects I can call from other scripts. What might one of those scripts
look like, and how would tell Parrot to run postgres.pir? Similarly, when I
run postgres.pir, what tells Parrot to do something with the .pasm and
.declarations files?
Based on looking at that stuff, I'm thinking what we need to do is as follows
(this is all guessing, but slightly more educated guessing than it has been
previously):
* We need to write a file similar to postgres.pir loading whatever SPI, etc.
functions we want to expose. As distinct from postgres.pir specifically, our
code won't have to load a library, because it will already be running in a
Postgres backend.
* Either 1) PL/Parrot functions will have to explicitly load our PIR stuff (in
whatever way you load PIR stuff now, presumably; the answer to my first
question, above). Or 2) we'll run some PIR when we initialize the
interpreter to set up the namespace magically. If that will work, though, it
means we can run stuff in our interpreter and leave artifacts behind when we
exit, which raises the question of what artifacts normal PL/Parrot functions
might leave behind for other PL/Parrot functions on the same interpreter to
snoop at.
* Having done all that, presumably we're done with bare-bones SPI (well, there
are tests and docs to write...). But this is the bit where we can make
ourselves really useful, because SPI only provides two mechanisms for doing
useful things with data: SPI_getvalue(), which returns a string
representation of a value, and SPI_getbinvalue(), which returns the
PostgreSQL Datum object. Presumably we'll not want users having to fiddle
directly with the Datum type, but we could add all kinds of nice functions
here to convert Datums to various PMCs we'll helpfully provide. These data
types can include container types as well, so we can include a function in
* our SPI layer to convert a Datum or group of Datums to an Array or Hash PMC.
Which would rock :)