Обсуждение: plpgsql redesign (related to plpgsql check function)
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. Regards Pavel Stehule
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. - Heikki
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