On Wed, Jul 29, 2009 at 9:08 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice<prentice@cisco.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