Re: an idea, language SPI

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
>

In response to

Browse pgsql-hackers by date

  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