Re: plpgsql functions organisation
От | Adrian Klaver |
---|---|
Тема | Re: plpgsql functions organisation |
Дата | |
Msg-id | 55455FC6.2090801@aklaver.com обсуждение исходный текст |
Ответ на | Re: plpgsql functions organisation (Bill Moran <wmoran@potentialtech.com>) |
Ответы |
Re: plpgsql functions organisation
|
Список | pgsql-general |
On 05/02/2015 03:28 PM, Bill Moran wrote: > On Sat, 02 May 2015 15:06:24 -0700 > Adrian Klaver <adrian.klaver@aklaver.com> wrote: > >> On 05/02/2015 02:07 PM, Jeff Janes wrote: >>> On Sat, May 2, 2015 at 1:05 PM, Adrian Klaver <adrian.klaver@aklaver.com >>> <mailto:adrian.klaver@aklaver.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. Agreed, though in my case I drop into plpythonu when I want more complex solutions. > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: