We have already implemented python as an external interface, but not as
a procedural language inside the backend. Jan Wieck (jwieck@debis.com)
has discussed implementing a procedural language, but I am not sure how
far he has gotten.
> [Sorry, my ISP managed to get itself on the RBL, so hub.org rejects my mail,
> and if I send mail to "hackers" mailing list from a different account, it
> gets rejected because that account isn't a subscriber to the list. So, I'm
> sending this individually.]
>
> I'm looking at implementing a procedural language for postgresql, and I
> have a few questions I'd like to get feedback on before I start.
>
> 1. First of all, is anybody already working on this? I would like to
> avoid duplication of effort, if possible.
>
> 2. Looking at the code, it seems that I basically need to do three things:
> write a parser (using gram.y as a model), implement code to handle flow-
> control nodes in the parse tree for the executor, and write a small bit of
> glue for a handler (starting with the stub in "man create_language").
> Is this basically correct? Is there anything in these areas that is
> particularly fragile that I need to watch out for?
>
> 3. I want to use Python as a model, because Python syntax is very simple,
> and the semantics are a very good fit with the postgres backend. One
> problem I see, though, is that Python is dynamically typed, and looking
> at the backend code, it looks like postgres is statically typed. If you
> have a Datum, there doesn't seem to be any way to know what's in it.
> Comments? Suggestions?
>
> Thanks.
>
> -Michael Robinson
>
>
>
>
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
