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.

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   |/

Wed, 09 Jun 1999 11:05:57 +1000
Philip Warner <pjw@rhyme.com.au>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)

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 function
 executed
 Add some string and regex manipulation functions.
 Add exception 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 ...

Wed, 09 Jun 1999 13:34:13 +0400 (MSD)
Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)
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   |/

Wed, 09 Jun 1999 22:23:20 +1000
Philip Warner <pjw@rhyme.com.au>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)
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 just GOSUB without RETURN.


Wed, 9 Jun 1999 16:35:59 +0400 (MSD)
Oleg Broytmann <phd@emerald.netskate.ru>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)

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 ...

Wed, 09 Jun 1999 16:39:21 +0400 (MSD)
Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)
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

Wed, 09 Jun 1999 22:28:19 +0300
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)
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) #



Wed, 9 Jun 1999 23:51:26 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] PL/Lang (was: Priorities for 6.6)