Re: PL/pgSQL 'i = i + 1' Syntax - Mailing list pgsql-hackers

Ühel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
> 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...

I dont think that having separate _parameters and _locals is a good idea
(then we would probably also need _const :) ). lerts have just _vars OR
_locals.

> IIRC, Oracle handles this by allowing you to prefix variables with the
> name of the function. 

what happens if your function name is the same as some table name or
local record variable name ? would it still bite newcomers ? 

> 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 got the impression that this was either a) tied together with adding
*procedures* in addition to functions or b) planned somehow to be solved
by using schemas

> > > 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).

or perhaps have plpgsql_lint as a separate external tool or as a
database function :)

I guess it is hard to make a strict mode, when the need for using $ in
first place comes from inability to distinguish between fields and
variables :)

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com

NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please advise the sender
by reply email and immediately delete the message and any attachments
without copying or disclosing the contents.