Another problem I found with the PL code was that it took the fmgr()
macro, and made it call a function call to fmgr_addr, which just killed
performance.

I made fmgr_addr() a macro too.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Tue, 3 Feb 1998 14:57:46 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
PL code and fmgr_addr
> 
> Another problem I found with the PL code was that it took the fmgr()
> macro, and made it call a function call to fmgr_addr, which just killed
> performance.
> 
> I made fmgr_addr() a macro too.
> 
> -- 
> Bruce Momjian
> maillist@candle.pha.pa.us
> 
> 

    Just to let you know - after fixing some other problems
    caused by the bpchar trouble my PLtcl tests went through
    again. Looks the macroization is O.K.


Until later, Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


Thu, 5 Feb 1998 16:55:16 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PL code and fmgr_addr
On Thu, 5 Feb 1998, Jan Wieck wrote:

> > 
> > Another problem I found with the PL code was that it took the fmgr()
> > macro, and made it call a function call to fmgr_addr, which just killed
> > performance.
> > 
> > I made fmgr_addr() a macro too.
> > 
> > -- 
> > Bruce Momjian
> > maillist@candle.pha.pa.us
> > 
> > 
> 
>     Just to let you know - after fixing some other problems
>     caused by the bpchar trouble my PLtcl tests went through
>     again. Looks the macroization is O.K.

	Do we have regression tests for this?



Thu, 5 Feb 1998 10:57:45 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] PL code and fmgr_addr
>
> On Thu, 5 Feb 1998, Jan Wieck wrote:
>
> > >
> > > Another problem I found with the PL code was that it took the fmgr()
> > > macro, and made it call a function call to fmgr_addr, which just killed
> > > performance.
> > >
> > > I made fmgr_addr() a macro too.
> > >
> > > --
> > > Bruce Momjian
> > > maillist@candle.pha.pa.us
> > >
> > >
> >
> >     Just to let you know - after fixing some other problems
> >     caused by the bpchar trouble my PLtcl tests went through
> >     again. Looks the macroization is O.K.
>
>    Do we have regression tests for this?
>
>
>

    No  -  since  PLtcl isn't part of the distribution up to now.
    And I think that even if we include PLtcl into  the  dist  we
    shouldn't  include  it  into  the  regression  tests  because
    building PLtcl requires a  Tcl  installation  (at  least  the
    libtcl??.so and tclConfig.sh).

    But  it  would  be  O.K.  for  me to include the PLtcl to the
    contrib directory and setup a separate test suite there.


Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Thu, 5 Feb 1998 17:13:36 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PL code and fmgr_addr
On Thu, 5 Feb 1998, Jan Wieck wrote:

> >
> > On Thu, 5 Feb 1998, Jan Wieck wrote:
> >
> > > >
> > > > Another problem I found with the PL code was that it took the fmgr()
> > > > macro, and made it call a function call to fmgr_addr, which just killed
> > > > performance.
> > > >
> > > > I made fmgr_addr() a macro too.
> > > >
> > > > --
> > > > Bruce Momjian
> > > > maillist@candle.pha.pa.us
> > > >
> > > >
> > >
> > >     Just to let you know - after fixing some other problems
> > >     caused by the bpchar trouble my PLtcl tests went through
> > >     again. Looks the macroization is O.K.
> >
> >    Do we have regression tests for this?
> >
> >
> >
> 
>     No  -  since  PLtcl isn't part of the distribution up to now.
>     And I think that even if we include PLtcl into  the  dist  we
>     shouldn't  include  it  into  the  regression  tests  because
>     building PLtcl requires a  Tcl  installation  (at  least  the
>     libtcl??.so and tclConfig.sh).
> 
>     But  it  would  be  O.K.  for  me to include the PLtcl to the
>     contrib directory and setup a separate test suite there.

	Wait...didn't we just do a patch so that PLs could be used?  Do we
have regression tests for that?  LIke we have to triggers?

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 5 Feb 1998 19:03:09 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] PL code and fmgr_addr
>
> On Thu, 5 Feb 1998, Jan Wieck wrote:
>
> > >
> > > On Thu, 5 Feb 1998, Jan Wieck wrote:
> > >
> > > > >
> > > > > Another problem I found with the PL code was that it took the fmgr()
> > > > > macro, and made it call a function call to fmgr_addr, which just killed
> > > > > performance.
> > > > >
> > > > > I made fmgr_addr() a macro too.
> > > > >
> > > > > --
> > > > > Bruce Momjian
> > > > > maillist@candle.pha.pa.us
> > > > >
> > > > >
> > > >
> > > >     Just to let you know - after fixing some other problems
> > > >     caused by the bpchar trouble my PLtcl tests went through
> > > >     again. Looks the macroization is O.K.
> > >
> > >    Do we have regression tests for this?
> > >
> > >
> > >
> >
> >     No  -  since  PLtcl isn't part of the distribution up to now.
> >     And I think that even if we include PLtcl into  the  dist  we
> >     shouldn't  include  it  into  the  regression  tests  because
> >     building PLtcl requires a  Tcl  installation  (at  least  the
> >     libtcl??.so and tclConfig.sh).
> >
> >     But  it  would  be  O.K.  for  me to include the PLtcl to the
> >     contrib directory and setup a separate test suite there.
>
>    Wait...didn't we just do a patch so that PLs could be used?  Do we
> have regression tests for that?  LIke we have to triggers?

    Up  to  now we don't have a PL that is independent. The patch
    only prepared the backend for a generic PL interface  (CREATE
    PROCEDURAL  LANGUAGE  and  the fmgr changes that a handler is
    called for functions of that language) and I tested all  that
    with PLtcl, which for sake isn't in the dist right now.

    The  current  regression tests only enshure that the slightly
    modified fmgr doesn't break anything that worked before.  And
    I  think  this  should  be  the  state  until  we have a real
    PL/pgSQL.

    I have some ideas  for  a  PL/pgSQL.  And  I  will  create  a
    regression test for it while implementing.

>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org
>
>
>


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Fri, 6 Feb 1998 11:15:58 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] PL code and fmgr_addr