2013/5/28 Heikki Linnakangas <hlinnakangas@vmware.com>:
> On 28.05.2013 11:00, Pavel Stehule wrote:
>>
>> Hello all
>>
>> I am searching way how to push our plpgsql_check_function to upstream.
>> One possibility is redesign of plpgsql architecture.
>>
>> Now, we have two stages -> compilation and execution, and almost all
>> compilation logic is in gram file. If I understand to this design
>> well, then a reason for it is a possibility to raise user friendly
>> error messages with location specification. Now, we are able to raise
>> messages with location info outside gram file, so we can little bit
>> cleanup architecture by dividing current compilation to parsing and
>> compilation stage (recursive).
>>
>> A new compilation stage can be good place for placing current checks
>> and deep (sql semantic) check.
>>
>> This redesign contains lot of work, so I would to know all opinions
>> and I would to know, if this idea is acceptable.
>
>
> +1 for a redesign along those lines. I'm not sure what the rationale behind
> the current design is. I'd guess it has just grown that way over time
> really, without any grand design.
>
> While we're at it, it would be nice if the new design would make it easier
> to add an optimization step. I'm just waving hands here, I don't know what
> optimizations we might want to do, but maybe it would make sense to have a
> new intermediate language representation that would be executed by the
> executor, to replace the PLpgSQL_stmt_* structs. OTOH, perhaps it's better
> to not conflate that with the redesign of the grammar / compiler part, and
> keep the executor and PLpgSQL_stmt* structs unchanged for now.
I played with some simple intermediate language - see
https://github.com/okbob/plpsm0
but without JIT it is significantly slower than current design :-(
Regards
Pavel
>
> - Heikki