Re: Out parameters handling

Dimitri Fontaine <dfontaine@hi-media.com> writes:
> I'd sure be happy not having to do it explicitly, but schema-style  
> prefixing has the drawback of needing to avoid any user defined  
> schema.

No, not really, because it'd be the wrong number of naming levels.

Assuming that we were to switch to Oracle-style naming rules, we
would have:
x in the context of a table name = table x
x.y in the context of a table name = table y, schema x
x in the context of an expression = first of    column x from some table of the current command    most-closely-nested
plpgsqlvariable x
 
x.y in the context of an expression = first of    column y from table x of the current command    plpgsql variable y in
blockx
 

The important point here is that the main SQL parser can tell whether
it's looking at a table name or a column name, whereas plpgsql is
currently too stupid for that and will always substitute for a name
that matches a plpgsql variable name.  Once we get rid of that problem
there isn't really any conflict with schema names.  You might have a
conflict between table aliases and block names, but that can be
dealt with by local renaming of aliases within the problematic command.

(Note: as pointed out by Pavel, it's already the case that named
parameters are implicitly assigned a block name equal to the function
name; so you can qualify them if you have to.)
        regards, tom lane