Thread: Re: [HACKERS] PL/Lang (was: Priorities for 6.6)
At 14:40 8/06/99 +0400, you wrote: >Hello! > >On Tue, 8 Jun 1999, Jan Wieck wrote: >> This time, the Perl interpreter has to become a silly little >> working slave. Beeing quiet until it's called and quiet >> again after having served one function call until the big >> master PostgreSQL calls him again. >> >> This flexibility requires a real good design of the >> interpreters internals. And that's what I'm addressing here. > > I know exactly 1 (one) program that incorporate (embed) Perl interpreter >- it is editor VIM (well-known vi-clone from www.vim.org). I think anyone Apache also has Perl very nicely embedded (as opposed to available through indirect CGI calls); when it is embedded it automaticallyreloads and recompiles changed scripts. I presume that the Apache code may be useful in this process. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On 09-Jun-99 Philip Warner wrote: > At 14:40 8/06/99 +0400, you wrote: >>Hello! >> >>On Tue, 8 Jun 1999, Jan Wieck wrote: >>> This time, the Perl interpreter has to become a silly little >>> working slave. Beeing quiet until it's called and quiet >>> again after having served one function call until the big >>> master PostgreSQL calls him again. >>> >>> This flexibility requires a real good design of the >>> interpreters internals. And that's what I'm addressing here. >> >> I know exactly 1 (one) program that incorporate (embed) Perl interpreter >>- it is editor VIM (well-known vi-clone from www.vim.org). I think anyone > > Apache also has Perl very nicely embedded (as opposed to available through > indirect CGI calls); when it is embedded it automatically reloads and > recompiles changed scripts. IMHO, It's bad practice to embed Perl, C++ and so on into postgres. because it slow down postgres, increase memory requirement and amount of leaks and errors. Postgres should use it's own language like plpgsql, and it's better to point your mind to improve and speed up it. For example:Add pre-compilation and syntax check while create functionexecutedAdd some string and regex manipulation functions.Addexception handling. All completely non standard thing may (and should) be done outside of postgres or in worst case by DYNALOAD mechanic. You can look at Apache's mod_perl and mod_php3 to compare two ways mentioned above: First - embedding perl with all it's history and lots of function completely unnecessary and inconvenient for web programming. Second - php3 - language initially developed to embed into apache. --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
At 13:34 9/06/99 +0400, you wrote: > >IMHO, It's bad practice to embed Perl, C++ and so on into postgres. >because it slow down postgres, increase memory requirement >and amount of leaks and errors. You can't possibly mean to say Perl is a slow, leaky memory hog! ;-} Do I detect a conspiracy here? (Oleg?) >Postgres should use it's own language like plpgsql, and >it's better to point your mind to improve and speed up it. > >For example: > Add pre-compilation and syntax check while create function > executed At least a syntax check... > Add some string and regex manipulation functions. > Add exception handling. > These all sound like a good idea. Jan: If I volunteer to attempt any of these, can you provide advice? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On 09-Jun-99 Philip Warner wrote: > At 13:34 9/06/99 +0400, you wrote: >> >>IMHO, It's bad practice to embed Perl, C++ and so on into postgres. >>because it slow down postgres, increase memory requirement >>and amount of leaks and errors. > > You can't possibly mean to say Perl is a slow, leaky memory hog! ;-} No - it just a huge bug ;-))I like Perl - but it's really too big to be combined with something else. > > Do I detect a conspiracy here? (Oleg?) I hope not. No masquerading is installed - I'm Dmitry yet. ;-)) > >>Postgres should use it's own language like plpgsql, and >>it's better to point your mind to improve and speed up it. >> >>For example: >> Add pre-compilation and syntax check while create function >> executed > > At least a syntax check... > > >> Add some string and regex manipulation functions. >> Add exception handling. >> > > These all sound like a good idea. Thanks > > Jan: If I volunteer to attempt any of these, can you provide advice? > --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
On Wed, 9 Jun 1999, Philip Warner wrote: > You can't possibly mean to say Perl is a slow, leaky memory hog! ;-} > Do I detect a conspiracy here? (Oleg?) I am not in the language wars, sorry :) > >For example: > > Add pre-compilation and syntax check while create function > > executed > > At least a syntax check... Python can store compiled bytecodes on disk. > > Add exception handling. Python is definetely good on this. I'll following the discussion. > ---------------------------------------------------------------- > Philip Warner | __---_____ > Albatross Consulting Pty. Ltd. |----/ - \ > (A.C.N. 008 659 498) | /(@) ______---_ > Tel: +61-03-5367 7422 | _________ \ > Fax: +61-03-5367 7430 | ___________ | > Http://www.rhyme.com.au | / \| > | --________-- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they justGOSUB without RETURN.
Dmitry Samersoff wrote: > > IMHO, It's bad practice to embed Perl, C++ and so on into postgres. > because it slow down postgres, increase memory requirement > and amount of leaks and errors. > > Postgres should use it's own language like plpgsql, and > it's better to point your mind to improve and speed up it. > > For example: > Add pre-compilation and syntax check while create function > executed > Add some string and regex manipulation functions. > Add exception handling. What we really need is a better PL interface, the current one has quite a few limitations. Corba may help here, but _not_ a simple Corba wrapper of existing api > All completely non standard thing may (and should) be done outside of postgres > or in worst case by DYNALOAD mechanic. Currently we are doing it in your "worst case" way :) the v6.5 has even special scripts to create/destroy PLs. Only SQL and internal (compiled-in C) are "embedded" in non-removable way. Even PL/PGSQL must be installed to be used > You can look at Apache's mod_perl and mod_php3 to compare two ways > mentioned above: > > First - embedding perl with all it's history and lots of function completely > unnecessary and inconvenient for web programming. > > Second - php3 - language initially developed to embed into apache. Compare this to Zope - using an advanced language to craft a special tool (in this case application server), which can both be used from other servers but also has its own server (also written in python) which can outperform apache in many usage patterns. And it has even a small SQL server (gadfly) embedded for both example of SQL adapter and for smaller scale work (also written in python) I think this achieves both the slickness of php3 and with extendability of perl. Now - what has it to do with embedding languages in PostgreSQL? IMHO having better support for PLs should go further than just calling functions in SELECT or triggers - to make it possible for people to easily add new types/indexing schemes the PL should also be usable for input/output functions, access methods and maybe even for prototyping new fe/be protocol. I hope to get a draft implementation of this in 6.5 before its official launch :) ------------------- Hannu
Hannu Krosing wrote: > What we really need is a better PL interface, the current one has > quite a few limitations. Corba may help here, but _not_ a simple > Corba wrapper of existing api Actually I'm a little in doubt if calling it an interface isn't gone too far. The only difference (from the call handlers point of view) is that the fmgr calls one and the same C entry point for different functions and passes therefore the OID of the function meant. So in reality it's more another call technique than an interface. On the point on CORBA I say: If Someone can create a general interface that makes integration of external languages/applications as easy so little old ladies and 12 year old pacman players can do it, than he should. If that new, fantastic, glory technique is based on CORBA or COBOL, I wouln't mind - I would shout a welcome! I'm not able to produce such a magic thing. All I can create are things like PL/Tcl, PL/pgSQL, the actual pain of the rule system and some other ugly ones. And as long as noone comes up with the above peace of magic, I'll go on providing the things I can create. It was hard to write them, so it should be hard to use them. I only try to make it not as hard as to learn an entirely new language from scratch. In the PL/Tcl tree there is a little test suite. I'm sure that a Perl expert could create the same suite in a few minutes (like I did it) - but only in PL/Perl - never in PL/Tcl, because then he would have a larger learning curve ahead. Let people use the languages they're familiar with, and you'll get good, reliable, performat applications. Force them to use something they've never seen before and they'll "shoot theirself into the foot". To understand this one someone must (re)read: http://www.cs.rpi.edu/~edwardsb/shoot.in.foot.html > > > All completely non standard thing may (and should) be done outside of postgres > > or in worst case by DYNALOAD mechanic. > > Currently we are doing it in your "worst case" way :) > > the v6.5 has even special scripts to create/destroy PLs. Only SQL and > internal (compiled-in C) are "embedded" in non-removable way. > > Even PL/PGSQL must be installed to be used And I don't think that having PL/pgSQL to follow the generalized standard way all PL's must go is the worst case. IMHO it's the best of all cases. Think of other standards - ALL Windows applications must use the Windows API - except for those created by M$. Maybe they have a good reason not to use the Windows API - they know it's internals. > IMHO having better support for PLs should go further than just calling > functions in SELECT or triggers - to make it possible for people to > easily > add new types/indexing schemes the PL should also be usable for > input/output > functions, access methods and maybe even for prototyping new fe/be > protocol. For PL/Tcl, this time will surely come. When Tcl8.1 has settled so 8.0 could be considered the release that has to be supported for backward compatibility, I'll kick out the 7.6 support from PL/Tcl. This would again increase it's performance. The actual limitation not to be able to create data type input/output functions is because the call handler doesn't support it. Definitely, it could! It already has to lookup pg_type to find the input/output functions for the return- value/arguments. If the OID in the pg_type tuples in-/out- function is the one the call handler actually is called for, why not acting so? The PL/Tcl module you're seeing with v6.5 is mainly still the one I've developed based on Tcl7.6 (the fact that one and the same sources actually compile with 7.6 and 8.0 stands for itself). All the above features would have required the Tcl_Obj interface which was new to 8.0. But at the time I created it, 7.6 was the default in install packages of unices and surely there where many 7.5's still in use. I decided it would be better to first support most Tcl installations and later force those who used it to do an upgrade. > > I hope to get a draft implementation of this in 6.5 before its official > launch :) I'll be back... Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #