2013/5/28 Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
