Re: plpgsql functions organisation

Further to the point of saying functions are ineffiencent, consider the
fact that as of the current version of PostgreSQL, plpgsql
functions cannot be pre-optimized. So when they are referenced in a SQL
statement, PostgreSQL (optimizer) has load the
function from the catalogs, which involves overhead. If the function calls
another function, then the process has to be repeated, which involves
additional overhead. Ergo, that is not the most efficient way of doing
things.

On Sat, May 2, 2015 at 5:17 PM, Bill Moran <wmoran(at)potentialtech(dot)com> wrote:

> On Sat, 2 May 2015 14:07:31 -0700
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> > On Sat, May 2, 2015 at 1:05 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> >
> > wrote:
> >
> > > On 05/02/2015 10:12 AM, Melvin Davidson wrote:
> > >
> > >> AFAIK, you cannot "package" functions in PostgreSQL, but it is
> possible
> > >> to
> > >> call a function from within a function.
> > >>
> > >> That being said, I would seriously look at how and why you are writing
> > >> your functions
> > >> as functions that call other functions are not very efficient.
> > >>
> > >
> > > I am not following. That is what packaging is about, separating out
> 'units
> > > of work' so they can be combined as needed. Part of that is using
> existing
> > > functions in new functions/classes. In fact in the Postgres source I
> see
> > > this in many places. Now it is entirely possible I missed a memo, so I
> am
> > > open to a more detailed explanation of the inefficiencies involved.
> > >
> >
> > The Postgres source is written in C, not in plpgsql. C has a good
> > optimizing compiler and plpgsql doesn't.
>
> Maybe that's a roundabout way of saying that if your functions are
> complex enough to require calling "sub-functions" they might be
> justifying being writting in C?
>
> --
> Bill Moran
>

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.