plpgsql redesign (related to plpgsql check function)

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers