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.
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.
regards, tom lane