Robert Haas <robertmh...@gmail.com> writes: > On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice<prent...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers