Re: RFD: Don't force plpgsql IN parameters to constant

On Wed, Jul 29, 2009 at 9:08 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice<prentice(at)cisco(dot)com> wrote:
>>> Is there a reason we force plpgsql IN parameters to constant?
>
>> Wow.  I can imagine about a thousand ways that this could break
>> existing applications.  I would not be prepared to bet a dollar that
>> anything I've written would survive the impact unscathed.
>
> Really?  AFAICS the only impact is that if you tried to assign to a
> parameter variable, it would do it instead of throwing a compile-time
> error.  It's hard to imagine that breaking any code that works now.

Yeah, I'm wrong. Sorry.

> It's true that doing this might foreclose some implementation shortcuts
> in future versions of plpgsql, but it's not going to be an issue in
> anything that works remotely like the way that plpgsql variables work
> now.
>
> Also, if we think it's a good idea, why are we only forcing CONST
> for scalar arguments and not composite arguments?  (The fact that
> plpgsql doesn't even have a way to mark composites as CONST might
> be the reason ;-), but it's surely not a real good reason.)  And
> special trigger arguments like tg_name aren't marked CONST either,
> for even less reason.
>
> Now having said all that, I'm not really in favor of Steve's
> proposal --- it seems like it mostly would be encouraging dubious
> programming practices.  But it's hard to say that the arguments
> against are more than theoretical/aesthetic ones.
>
> Does anyone happen to know how it works in Oracle's PL/SQL?
> I think that following their lead is usually the argument-settler
> when it comes to plpgsql behavior.

Hmm, well if I understand this correctly (now), it's similar to allowing:

void
test2(int a)
{
a = 2;
return;
}

...which is a fairly common programming practice that I don't think is
particularly considered bad style, or at least certainly not by
everyone.

...Robert