From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: an idea, language SPI |
Date: | 2009-01-05 20:35:02 |
Message-ID: | 162867790901051235o1cf6025fjcf74485195e21bcd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/1/5 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> I am thinking about reimplementation PL/pgPSM, where code should be
>> shared with PL/pgSQL. I have idea of some middle language, that should
>> be used for both languages. This language could be based on SPI
>> interface with some procedural elements (if, jmp, return).
>
> You mean exposed to the user? Why would anyone want that?
yes, minimally it should work like decompiler and test environment for runtime.
plpgsql and plpgpsm should be compiled to spi language, and this
should be interpreted with spi interpret.
I expect really general runtime, that should be used for any purposes
- maybe for T-SQL, for some emulation layers. Current runtime is based
on fat layer over SPI, where any optimizations are difficult. Next
compiler should better generate code based on SPI or
DirectFunctionCall interface. I am searching some p-code, for stored
procedures, and this only idea, - to define this p-code near SPI.
Pavel
By the time
> you had added enough features to it to be usable, you'd have plpgsql
> or equivalent.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-05 20:42:01 | Re: Status of issue 4593 |
Previous Message | Joshua D. Drake | 2009-01-05 20:23:49 | Re: Filtering WAL records in recovery |