BTW, I do wish you could change the label of the scope that arguments went into, so that you could use that label to refer to function parameters. If we allowed that it'd perhaps be the best of both worlds: you'd be guaranteed access to all auto variables and parameters, and that access wouldn't need to be tied to the function name (which can be both painful and error prone).
We can talk about compiler directive.
PRAGMA auto_variables_label(xxxx) -- require function scope only
If we know a list of all auto variables, then it can be on function or block level - it can create aliases.
Oh, the problem is that if you have an argument with the same name as an auto variable you're in trouble.
I didn't well explained my idea
It is similar to your plpgsql scope. You are introducing the convention. I proposed a explicit specification. The result is similar.
Probably the easiest thing is to have a scope that sits above the scope containing the arguments, and then allow the user to rename both scopes if so desired. So in effect you'd end up with
<<plpgsql>> -- new scope DECLARE FOUND; etc BEGIN <<function_name>> DECLARE argument_1; argument_2; BEGIN -- User supplied block goes here, with optional label END; END;
It is similar to
PRAGMA auto_variables_namespace(plpgsql);
BEGIN
...
END;
Using PRAGMA is more verbose - it is useful for code audit, review - it is speaking "I will overwrite some auto variables here, and I need special namespace"
plpgsql_check, maybe plpgsql self can raise warning if these variables are shadowed and some option/pragma is not used. Maybe current extra check does it already.
Alternatively, we could do...
<<function_name>> DECLARE FOUND; etc BEGIN DECLARE-- User's DECLARE argument_1; argomuent_2; -- User supplied declare code BEGIN -- User's BEGIN .... END
That removes one level of nesting. It's probably better to go with the first option though, since it's simpler.
You are forgot on function paramaters - somebody can use a function argument like FOUND, .. So auto variables should to be declared in most top namespace.
Usually it is invisible for users - one, two more namespaces has zero cost for compilation and absolute zero impact for evaluation.
In both cases, I'd really like the ability to rename those blocks. #pragma would be fine for that.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)