On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
> A less disruptive change would be to have some predefined "record" where
> all local variables belong to, perhaps called 'local' or '_local_' :) so
> one could access both input parameter inp_orderdate and declared
> variable var_orderdate as local.inp_orderdate and local.var_orderdate
> respectively ? The old use (without local.) should still work.
That might be useful for othing things, too. Having _local. and
_parameters. could be handy, for example. But I'm not sure if this is
better than using $ or not...
IIRC, Oracle handles this by allowing you to prefix variables with the
name of the function. You can also have package-level variables, which
can be handy (whatever happened to the discussion about adding packages
or something similar to plpgsql??)
> > I think it would be better to at least strongly recommend always
> > prefixing variables and parameters with something.
>
> At least we should use such convention in our sample code in docs.
Yes, at a minimum.
> > I'd argue that it'd
> > be even better to put us on the road of eventually mandating plpgsql
> > variables be prefixed with something (like $), but I'm not holding my
> > breath on that one...
>
> I dont believe in mandating non-backward-compatible changes, but prefix
> $ may be one way to disambiguate vars and fieldnames.
Well, this could be made optional (strict mode).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
