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/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to