Hello Tom,
All what you wrote is true. plpgpsm copies-and-pastes about 30% of code and
It is terrible for long run. But when I can change it? Writing differnt
runtime is nonsense, better way is refactoring plpgsql and then sharing code
with its. It's not propable in 8.4 .. there will by lot of important
patches from 8.3, and it's mean so interpret wll not be in core before two
years. All your last patches I merged in one day.
In next months plpgpsm can follow plpgsql, or else. plpgpsm can be
"experimental" and can be used for integration into core and creating "SQL
procedural language API" in 8.5 (and plpgsql will be in 8.4, 8.5 without
changes) and in 8.6 plpgsql will be modified to use this API. This road
expect stable plpgsql for next two, three years. plpgpsm can solve some
questions about future plpgsql. It contains some others construct which is
foreign in plpgsql and plpgsql can be in Oracle's style forever (with
David's patch Oracle collections are possible).
Bigger problem for plpgpsm isn't runtime but users. It needs bigger discuss
about integration into core, and it isn't possible without integration into
core. Current API can be dismissed in others API. With variable API we can
drop variables substitution in SQL, FAST SQL call can be part of SPI. But
all needs time. From plpgsql view simple change of caching was big patch. I
will be happy if 8.4 will contains true session variables. It can be used in
SQL languages later. I afraid so all these steps needs long time.
plpgpsm is ready. It's patch without dependencies and has not influence to
other parts of postgresql. I am working on documentation now. Czech version
is completed, waiting for translation to english.
Regards
Pavel Stehule
>* [PATCHES] plpgpsm /Pavel Stehule/
>
>I think this has to be held for 8.4: it was submitted too late for the 8.3
>feature deadline, and in fact I don't recall that there was any community
>discussion/consensus on accepting it into core at all. Another big
>problem is that it largely copies-and-pastes the plpgsql code, which I
>think is an unacceptable maintenance burden in the long run. We need to
>consider whether we can't refactor to avoid code duplication.
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/