Re: Why are stored procedures looked on so negatively?

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To:
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why are stored procedures looked on so negatively?
Date: 2013-08-05 02:01:01
Message-ID: 51FF075D.8000800@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 08/02/2013 09:18 PM, Merlin Moncure wrote:
> On Fri, Aug 2, 2013 at 1:49 AM, Chris Travers <chris(dot)travers(at)gmail(dot)com> wrote:
>> Here's my $0.02
>>
>> Stored procedures have a bunch of problems historically. Part of this is
>> because the interface traditionally is pretty spartan, and partly because
>> some people take them too far.
>>
>> The first issue is that if you have a stored procedure which takes 2
>> arguments and you need to extend it to three, then you have to change every
>> call in the calling application. This can create a maintenance problem.
>> Variadic functions help somewhat but there are limits to what a variadic
>> function can do here.
>
> This is true of most popular languages.

I think part of the issue is that people tend to consider stored
procedures part of the application's internal implementation where you
just change all the call sites when you change the function.

Normally stored proc are really more like a library API - something
that's a bit of a pain to change due to asynchronous updates of apps and
interface, multiple interface users, etc.

If you think about them that way the question "should this be done in
apps or in a stored proc" must be asked for each individual procedure.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message BladeOfLight16 2013-08-05 02:10:06 Re: Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, re-installation failure PLEASE CAN SOMEONE HELP!! (nearly fixed)
Previous Message Michael Paquier 2013-08-04 23:06:52 Re: xlog min recovery request ... is past current point ...