Re: plpgsql functions organisation

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Melvin Davidson <melvin6925(at)gmail(dot)com>, Yves Dorfsman <yves(at)zioup(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: plpgsql functions organisation
Date: 2015-05-02 22:28:06
Message-ID: 20150502182806.c7954b2fa5a0ea346b5dc119@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 02 May 2015 15:06:24 -0700
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:

> On 05/02/2015 02:07 PM, Jeff Janes wrote:
> > On Sat, May 2, 2015 at 1:05 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> > <mailto: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.
>
> Does this actually matter? I am a biologist that backed into computing,
> so I realize I am weak on the fundamentals. Still the scientist in me
> wants data backing assertions. As I understand it plpgsql works close to
> the server and is optimized to do so. I know writing in C would be a
> better solution. Still is calling plpgsql functions inside plpgsql
> really a bad thing when just considering plpgsql?

The answer to that is the same answer to so many other things: it depends.

plpgsql functions are slower than C. They also lack a lot of language
features that C has. That being said, if they're meeting your needs, then
don't worry about it. plpgsql is around because for most people, it works
well enough. There are certainly cases when you want to create very complex
logic in the database and plpgsql is liable to make that difficult. But
there are a lot of cases where having to manage pointers and a build
environment and all the things that go with C aren't justified, because
plpgsql has none of that complexity. There are advantages both ways.

The beauty of PostgreSQL is that you have both available and you
can choose whichever is best for your situation.

--
Bill Moran

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2015-05-02 23:36:19 Re: plpgsql functions organisation
Previous Message Melvin Davidson 2015-05-02 22:10:56 Re: plpgsql functions organisation